[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>-----Original Message-----
>From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
>Sent: Thursday, July 17, 2008 11:35 AM
>To: Stark, Barbara; Antonio Querubin
>Cc: v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>Barbara,
>
>Let me make sure I understand you. Are you agreeing to that fact that
>the WAN interface should have a global IPv6 address assigned to it
>because this is different from what you asked for in the past which was
>to only assign a link-local address to the WAN interface. Also assume,
>for the sake of closure to the question, that there is no Loopback
>interface enabled on the CPE Router - after all, our draft says the
>Loopback interface is optional.
I don't understand this. If it is a router, it follows
the weak end system model and it can source packets from
addresses assigned to any of its interfaces, including
virtual interfaces like a loopback. I do not see a
requirement for assignment of a non-link-local IPv6
address on the WAN interface.
Fred
fred.l.templin@boeing.com
>Further, even I agree with you that it's not wise for a CPE Router to
>respond to pings. But I appreciate what NTT did in their deployment
>because how else can one monitor health of the device in the home? The
>device has to at least rate limit ICMP if the device responds to it.
>Section 2.8 of RFC4241 is also not clear when it says "The CPE must
>return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo
>Request packet." What happens if the CPE received another ping
>req, say,
>2 secs later. Will the CPE reply? If yes, then I can launch a ping
>attack on this CPE sending one pings per x secs and the CPE keeps
>replying. That is why I mentioned rate limiting.
>
>Hemant
>
>-----Original Message-----
>From: Stark, Barbara [mailto:bs7652@att.com]
>Sent: Thursday, July 17, 2008 1:47 PM
>To: Hemant Singh (shemant); Antonio Querubin
>Cc: v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>I've looked over RFC4241. I think it accurately describes what needs to
>happen in a generic PPPoE environment -- except the section "2.8.
>Connectivity Monitoring". We do not currently require CPE routers to
>respond to ICMP echo requests. It's even an option in some of our
>routers for customers to disable responses to unsolicited ICMP
>messages.
>And we still don't have something called a "loopback interface". I also
>don't think we intend to provide a /48 in this mass market environment.
>Probably the smallest prefix would be a /56. I haven't seen any ARIN
>policy relating to required echo support, especially for an
>end customer
>with a /56.
>
>But I'm starting to wonder if we may just be experiencing another
>terminology problem, with "loopback interface".
>
>That is, I definitely agree that all CPE routers need to have a global
>address that can initiate and receive traffic to and from the Internet
>(over each logical WAN interface -- at the link layer or over PPP). I
>think this address can easily come from the prefix, and doesn't have to
>be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The
>CPE router must be able to act as a host device to the WAN.
>
>Clearly, there will be a link-local IP address on that WAN (link layer
>or PPP) interface. There may be a global IP address assigned
>by SLAAC or
>stateful DHCPv6. If there is, I think it would be useful to think about
>when the device might use or respond to messages to that
>global address,
>vs. global addresses it gives itself from the prefix. My preference
>would be to always use the prefix address for sending messages, by
>default (that is, unless configured to do otherwise). Incoming traffic
>to the SLAAC/DHCPv6 address might be blocked, by default (unless
>configured otherwise). Unless the device doesn't get a prefix; then it
>will need to use the SLAAC/DHCPv6 address.
>
>I also think it's not a bad idea for the CPE router to keep the /64 for
>itself that equates to the prefix it's given followed by zeroes, to get
>to 64 bits (which is my attempt at trying to generically
>describe what I
>think RFC4241 section 2.8 is saying). I think it's fine for the CPE
>router to be able to respond to echo requests to that /64, if that
>function (responding to echo requests from the WAN) is enabled.
>Barbara
>
>-----Original Message-----
>From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
>Sent: Tuesday, July 15, 2008 7:10 PM
>To: Stark, Barbara; Antonio Querubin
>Cc: v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>Barbara,
>
>Did you get a chance to look at our -02 draft and its reference to
>RFC4241? Please read RFC4241 to see what has NTT done in Japan to their
>ADSL IPv6 services.
>
>Thanks.
>
>Hemant
>
>-----Original Message-----
>From: Stark, Barbara [mailto:bs7652@att.com]
>Sent: Tuesday, July 15, 2008 5:34 PM
>To: Hemant Singh (shemant); Antonio Querubin
>Cc: v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>I would prefer if no statements were made as to number of physical WAN
>interfaces. We have some bonded DSL interfaces that have 2 physical
>interfaces that are bonded together at either the ATM or
>Ethernet layer.
>There are 2 physical WAN interfaces, but from the perspective of the IP
>portion of the access network, there is only one "logical" WAN
>interface
>on the router.
>
>I really would prefer to describe the behavior of a single link layer
>(L2) interface, rather than make any mention of physical interfaces
>(quantity, PHY, jack, or otherwise). I agree with your statement that
>this document's functionality needs to be abstracted from the physical.
>I really, really agree.
>Barbara
>
>-----Original Message-----
>From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
>Sent: Tuesday, July 15, 2008 4:51 PM
>To: Stark, Barbara; Antonio Querubin
>Cc: v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>Barbara,
>
>Thanks for this email. For the purposes of description of behavior of a
>CPE Router, all we are asking for is how many physical WAN interface
>ports will the CPE Router have? We have recommended one. We could care
>less about any other physical layer behavior. We are defining routing
>behavior that sits abstracted from link or physical layers. Where a
>layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP
>address acquisition does not perform DAD.
>
>Hemant
>
>-----Original Message-----
>From: Stark, Barbara [mailto:bs7652@att.com]
>Sent: Tuesday, July 15, 2008 4:17 PM
>To: Antonio Querubin; Hemant Singh (shemant)
>Cc: v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>I don't understand the relevance of mentioning PHY interfaces, PHY
>modems, or pure Ethernet switches, in a document about IPv6 behavior of
>CPE routers. A physical instantiation of a CPE router may
>indeed contain
>a PHY modem and Ethernet switch, but I don't see why that's relevant or
>needs to be called out in this document.
>
>I don't see any functionality described in this draft that
>changes based
>on the link layer or below. Certainly not if the link layer is
>Ethernet.
>
>I know that there do exist WAN PHY interfaces that do not have the IP
>running over either Ethernet link layer or PPP. Such IP
>interfaces will
>either exhibit the same behavior as described in this document, or they
>won't. If they do, that can be mentioned. If they don't, but have mass
>market relevance, it can be described how they differ. The WAN
>interface
>as an Ethernet link layer interface will cover all mass market retail
>routers, and the vast majority of DSL modem/routers. I can't speak for
>DOCSIS or UMTS, since I don't know those protocol stacks very well. If
>they don't use Ethernet for their link layers, do they have some other
>link layer that is similar to Ethernet? Is there any reason why that
>link layer shouldn't be considered the "WAN interface"?
>Barbara
>
>-----Original Message-----
>From: Antonio Querubin [mailto:tony@lava.net]
>Sent: Tuesday, July 15, 2008 2:00 PM
>To: Hemant Singh (shemant)
>Cc: Stark, Barbara; v6ops@ops.ietf.org
>Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>
>On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote:
>
>> Date: Tue, 15 Jul 2008 11:34:29 -0400
>> From: "Hemant Singh (shemant)" <shemant@cisco.com>
>> To: "Stark, Barbara" <bs7652@att.com>, v6ops@ops.ietf.org
>> Cc: Antonio Querubin <tony@lava.net>
>> Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
>>
>> Barbara,
>>
>> Since Antonio also raised a point about IPv6 addresses
>assigned to the
>
>> WAN interface (and the number of WAN interface(s)), we are
>combining a
>
>> reply to both you and Antonio.
>>
>> Barbara, when you say,
>>
>> "We have considered the possibility of a separate IP address for our
>> TR-069 management of the CPE routers that we supply, but would want
>this
>> to be a
>> configurable option."
>>
>> could you please elaborate. Does this separate IPv6 address get
>assigned
>> to the WAN side of the CPE Router? If yes, if the WAN interface is
>only
>> assigned a link-local address, then what network interface
>on the WAN
>> side does this IPv6 address get assigned to? One choice we
>have is to
>> assign the IPv6 address to the Loopback interface facing the
>WAN side.
>> Also, when reviewers ask for another network interface on the WAN
>side,
>> or another IPv6 address on the WAN side, could reviewers please
>> appreciate the fact that another WAN interface can mean two
>things for
>a
>> router. Either we have second physical WAN interface with a new
>> mac-address or we still have one WAN interface and the second WAN
>> interface is just a logical interface bound to the physical WAN
>> interface such that both the physical WAN interface and the logical
>> interface share a mac-address between them. Antonio and
>Barbara, which
>
>> one of these two interfaces are you talking about? Further,
>if one is
>> spawning logical interfaces on any router, once doesn't have to stop
>at
>> one extra interface. Go ahead and spawn more if one wants.
>
>Actually the discussion is confusing because the 'WAN'
>interface appears
>
>to mean different things depending on whether the layer 2 modem is
>integrated into the CPE router. For discussion purposes, in a general
>network configuration where all the components are separate
>you'll have:
>
> PCs
> |
> |
> |
>----- modem ----- switch ----- router/firewall ----- switch ----- PCs
> 1 A 2 B 3 C 4 D 5 E
>
>Devices B and D are just plain ethernet switches. Although
>the focus of
>
>this document seems to be on device C, it's interfaces, and
>the customer
>
>devices (E) behind it, the CPE router being discussed potentially
>encompasses functionality of devices A, B, C, and D.
>
>In the case where the modem is integrated, the interface that
>internally
>
>links the modem to the internal router device C may or may not be
>accessible to the consumer via external physical ports. If they are
>physically accessible, they need a different name than "WAN"
>if "WAN" is
>
>defined to be 1 above.
>
>If the modem is not integrated into your CPE device, then the "WAN"
>interface is just 2 and/or 3 above depending on whether
>additional "WAN"
>
>ports are provided by the vendor.
>
>However these multiple definitions of WAN interfaces are confusing,
>hence my earlier suggestion of using different names for the
>modem-router interface and the access provider interface.
>
>> Further, Antonio, when you say,
>>
>> "Additionally, for those vendors that wish to integrate the layer 2
>> (DSL/cable) modem as part of the CPE router (where the "WAN"
>> encapsulation is not ethernet), perhaps a separately named interface
>> definition might be appropriate to avoid confusion with "WAN"."
>>
>> In such a case, the WAN interface is a logical interface
>that bridges
>> the CPE Router to the broadband modem. We clarified the WAN
>interface
>> definition as follows with new text
>>
>> WAN interface - a single physical network interface on the
>standalone
>> CPE Router that is used to connect the router to the access
>network of
>
>> the Service Provider. When the CPE Router is embedded in a
>device that
>
>> connects to the WAN, this interface is a logical network interface
>that
>> bridges the device to the CPE Router. Some devices which can have an
>> embedded CPE router are: a cable or DSL modem, or a cellular
>telephone,
>> etc.
>>
>> When we publish our next revision of the draft, we will include new
>text
>> for the WAN interface definition.
>
>How about this. If you want to tie the WAN interface to the internal
>router:
>
>WAN interface - a network interface on the CPE Router that is used to
>connect the router to the access network of the Service Provider. When
>a CPE Router is embedded in a device that connects to the service
>provider
>
>via a non-ethernet connection, this interface is the logical interface
>that connects the internal router to the internal bridge. Some devices
>which can have an embedded CPE router are: a cable or DSL modem, or a
>cellular telephone, etc.
>
>SPA (service provider access) interface - a non-ethernet physical
>network interface that is bridged to the WAN interface and directly
>connects to the access network of the Service Provider.
>
>But if you want to keep the definition of WAN tightly coupled with the
>physical external port then something like this might be more suitable:
>
>WAN interface - a network interface on the CPE Router that is used to
>connect the router directly to the access network of the Service
>Provider.
>When a CPE Router is embedded in a device that connects to the service
>provider via a non-ethernet connection, this physical interface is
>bridged to the router via an internal modem. Some devices which can
>have an embedded CPE router are: a cable or DSL modem, or a cellular
>telephone, etc.
>
>WANEA (WAN Ethernet Access) interface - an optional ethernet interface
>that is bridged to the WAN interface and provides additional direct
>access to the Service Provider network.
>
>You may want to call it something other than WANEA :)
>
>Antonio Querubin
>whois: AQ7-ARIN
>
>*****
>
>The information transmitted is intended only for the person or
>entity to
>which it is addressed and may contain confidential, proprietary, and/or
>privileged material. Any review, retransmission, dissemination or other
>use of, or taking of any action in reliance upon this information by
>persons or entities other than the intended recipient is prohibited. If
>you received this in error, please contact the sender and delete the
>material from all computers. GA621
>
>
>
>*****
>
>The information transmitted is intended only for the person or
>entity to
>which it is addressed and may contain confidential, proprietary, and/or
>privileged material. Any review, retransmission, dissemination or other
>use of, or taking of any action in reliance upon this information by
>persons or entities other than the intended recipient is prohibited. If
>you received this in error, please contact the sender and delete the
>material from all computers. GA622
>
>
>
>