[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
Barbara,
No apologies needed! Thanks for the quick reply back. So now, you from AT&T and Shin from NTT, Japan are on the same page wrt global IPv6 address on the WAN interface. Shin has also asked for a global IPv6 address as a must for the WAN interface. From the -00 version of our draft we have been saying the WAN interface acquires a global address. Further, Mikael on this thread has said he wants the WAN interface to only acquire a link-local but the CPE Router spawn an Loopback interface to which a global IPv6 address is assigned - we have already said in our draft this Loopback interface is optional and your deployment can ignore using it. I'd also like to point out that the configuration required by Mikael is essentially the same as assigning a global IPv6 address to the WAN interface.
Yes, there was a reason why we didn't add text in the Numbered model to say that the global IPv6 address for the WAN interface may be assigned from the IA_PD. We wanted to be careful about it. Here is an example. The IA_PD obtained by the CPE Router is a /56. The CPE Router sub-delegates this prefix to a /64 for the LAN interface(s). So if a naïve implementation picked a global address for the WAN from the /64, then the WAN and the LAN are in the same IPv6 subnet - that's wrong because the WAN and LAN interface(s) are physically different network segments for the CPE Router and hence they must have different subnets to route traffic between them. What one has to do is pick a global address for the WAN interface from the /56 IA_PD. We can add new text to the Numbered model to cover your suggestion.
As for your other question in another email, no, I haven't seen anyone settle on what prefix length to dole out in the IA_PD - meaning /56 or /48 or what have you. That is why we have stayed away from specifying any prefix length in our draft.
Thanks for the mention of other "health" check mechanisms. At least when the CPE Router is embedded in a cable or DSL modem, I am sure the two broadband deployments have their own heartbeat between CMTS and cable modem or DSLAM and the DSL modem. Personally I don't like an ICMPv6 mechanism because it susceptible to attacks.
Hemant
-----Original Message-----
From: Stark, Barbara [mailto:bs7652@att.com]
Sent: Thursday, July 17, 2008 5:11 PM
To: Hemant Singh (shemant); Antonio Querubin
Cc: v6ops@ops.ietf.org
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt
I'm sorry to have caused you to think that I didn't want a global IP address on the WAN interface! What I meant to express, was that I didn't think a global IP address needed to be provided via SLAAC or stateful DHCPv6, but that it could be taken from the prefix. The definition of "Numbered Model" is very specific to getting the global address via SLAAC or stateful DHCPv6, and not any other way. So either the "Numbered Model" should also allow the global address to come from the prefix (especially if none comes from SLAAC or stateful DHCPv6), or the "Unnumbered Model" needs to mention that the WAN interface gets a global address from the prefix. I'm fine either way.
Yes, the WAN interface absolutely *must* have a global IP address that it uses for sending and receiving IP messages, as far as I'm concerned.
The "health" of the connection can be determined in a variety of ways.
PPP has messages for testing the PPP connection. I forget what the access network uses in IPv4. I know that inside the home we use ARP (for
IPv4) to test whether the device is still there. There are also PHY and
L2 layer tests to see if those layers are working. I can go ask the access network guys what we do for IP over Ethernet. In addition to these access network methods, our devices have a "heartbeat". They are expected to periodically "phone home" to the TR-069 server. For the health of the device (above and beyond whether the IP connection is up or down), we rely on TR-069.
FYI: Note that TR-069 is just some remote procedure calls and XML config parameters that run over (SOAP)/HTTPS/TCP/IP. Pretty basic. One big difference between TR-069 and SNMP is that TR-069 requires the CPE to initiate the connection (pull model). The XML config parameters are the analog of SNMP MIBs.
Barbara
-----Original Message-----
From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
Sent: Thursday, July 17, 2008 2:35 PM
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.
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