Re: Posted a new copy of CPE Rtr draft

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 6 mrt 2009, at 23:27, Hemant Singh (shemant) wrote:

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-04.txt

now v6ops-ipv6-cpe-router-00, right?

Not having read the subsequent discussion yet, here is my feedback:

Most important issue:

"The CPE Router may also support prefix sub-delegation."

We should make this a MUST. I don't want to end up in the situation  
where I get a crappy DSL IPv6 CPE from my ISP and I can't use my own  
CPE because there is no subdelegation.

If that's too hard, then we must mandate the ability for ISP-provided  
CPEs to run in bridge mode. (But then that CPE would probably still  
need a global address for management.) Preferably the ISP-provided CPE  
would go in bridge mode automatically when a more capable CPE is  
present. I guess this could happen if the ISP-CPE receives a PD request.


In general, information is often repeated.


"A CPE Router is an IPv6 Node"

I would think it's a router... Or do you guys mean that in addition to  
being a router, it must also fulfill the node requirements? If so, may  
want to say so explicitly here.

"The WAN interface is preferred to be Ethernet encapsulated but it may  
support other encapsulations such as PPP."

What about ATM? (I used native IPv6 over ADSL = ATM with a Cisco  
826/827 for years.)

"If no LAN interface is present"

Then what is the function of the CPE?

   Before the CPE Router is initialized, the device must have IPv6
   enabled.  The CPE Router SHOULD support the ability to disable its
   IPv6 stack.  The CPE Router also has the ability to block or forward
   IPv6 traffic to and from the router's LAN interface(s).  [RFC2669]
   includes a MIB definition to block the IPv4 or IPv6 Ethertype in the
   upstream or downstream interface(s) of a device such as the CPE
   Router.  Some portion of this MIB may need to be modified for use
   with the CPE Router.

This kind of detail has the potential to obscure the forrest with  
largely unnecessary trees. On the other hand it's also not so detailed  
that it fully specifies what an implementation is supposed to do. But  
different vendors are likely to have different opinions on that,  
anyway. And if v6 can be disabled, why not v4?

"The CPE Router MUST support at least one of two WAN interface models,"

It takes very long until the other shoe drops, would be better to just  
say "numbered and unnumbered" and then start a new paragraph for the  
discussion of the numbered model.

   In the Numbered model, the WAN interface acquires a global unicast
   address (GUA) using a combination of SLAAC and stateful DHCPv6 for
   IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA)

So the CPE is required to support address assignment for its WAN  
interface with both DHCPv6 and stateless autoconfig? I don't like that.

"A Loopback interface"

I would say "assigning a stable global unicast address to a loopback  
interface" so as to not confuse people who live in a host-based world  
where loopback interfaces have ::1 as their address.

"The IA_PD is sub-delegated to the LAN interface(s)"

I would say "/64 subprefixes of the IA_PD provided prefix are assigned  
to a LAN interface or multiple LAN interfaces. If the IA_PD only  
provides a /64 (which is NOT recommended) this prefix is assigned to  
one LAN interface."

"Either the Loopback or the LAN interface can be used to source WAN- 
facing traffic."

Like what? (I guess NTP or something like that...)

"if the O bit is set in the RA, the WAN interface acquires other  
configuration information."

What if the O bit is not set? Doesn't the CPE always initiate stateful  
DHCPv6 in order to obtain a prefix?

"Other IPv6 configuration information is obtained using stateless  
DHCPv6."

I don't think it makes sense to perform both stateful and stateless  
DHCPv6.

"The Unnumbered model is incompatible with the strong host model  
[RFC1122] on the CPE router"

Which is irrelevant, the CPE is a ROUTER, and there are no "strong"  
routers, only "strong" hosts.

"where a device that uses the strong host model can operate as a CPE  
Router."

Such devices must not be allowed.

"The CPE Router may include a stateful DHCPv6 server to assign  
addresses to home devices connected via the LAN interface(s) of the  
CPE Router."

That seems rather pointless. And because it's only a MAY there's no  
need to specifically point this out in the text.

But I guess this means that DHCPv6 requests done by hosts on the LAN  
side are never propagated to the ISP?

"The home devices can also acquire addresses via SLAAC."

That's not very specific. Needs to be: the CPE MUST send router  
advertisements with a prefix option once a prefix is available.

   If the IA_PD changes, the CPE Router must reconfigure
   the LAN interface(s) with new IPv6 addresses derived from the new
   IA_PD and then also renumber the IPv6 ND RA configuration on the LAN
   interface(s).

Need to explain that the old and the new prefixes must overlap for  
some time to allow for graceful renumbering.

   This document recommends the RA sent out by LAN Interface(S) to be
   configured for SLAAC so that the prefix advertised in the RA is
   derived from the IA_PD assigned to the CPE Router by the Service
   Provider;

Requires

   the O-bit is also set so that the CPE Router can pass
   Domain Name Server(s) IPv6 address(es) to home devices.

Only if the CPE implements a stateless DHCPv6 server that  
redistributes the DHCPv6 info the router itself got from the ISP, or  
if the router acts as a DHCPv6 relay.

How are ULAs for configuration supposed to work? Obviously you can't  
print the address for configuration in the manual (it being randomly  
generated and all). So at the very least this has to work through the  
DNS. The problem is: how do you get rid of the ULA addresses on hosts  
once global addresses are available?

The only time ULAs outperform link locals is in the case of cascaded  
CPEs where you want to go from host X to CPE A through CPE B. With  
link locals that wouldn't work.

An alternative for the configuration address would be a well-known  
address, so users can be told to go to 2001:db8::1. This could work  
with link locals on the hosts as long as CPEs aren't cascaded.

   initiates L2TPv2 tunnel from
   the CPE Router to tunnel IPv6 data from the home over an IPv4
   network.  The feature is enabled before any IPv6 host in the home is
   connected to the CPE Router or the WAN interface of the CPE Router  
is
   operational.

What does this mean?

It is important that delays or failure with the softwire stuff doesn't  
delay the initiation of native IPv6.

Also, "softwires" is the IETF wg, please use the name of the protocol.

Why is this under the PPP heading?

5.7.  Stateful DHCPv6 Server (CORE)

   The CPE Router may support a stateful DHCPv6 server to serve clients
   on the CPE Router LAN interface(s)

Core but not a requirement???

   If the CPE router supports
   cascading of routers through automatic prefix sub-delegation, the  
CPE
   router MUST support a DHCPv6 server or DHCPv6 relay agent.

(see above). Having a server or a relay are very different for the  
ISP, not good to leave both options open because now the ISP has to  
support both.

Is it mentioned anywhere that if a CPE supports subdelegation, it must  
also be capable of installing routes towards the router that has a  
subdelegation?

"The CPE Router MAY support RIPng in the home network."

For what purpose? RIP is a terrible routing protocol...

   Each of the WAN and LAN interface(s) of the CPE Router must have its
   own L2 (e.g.  MAC) address.

Why? This may make vendors limit the number of interfaces.

"The CPE Router supports ND protocol"

the ND protocol

   both the WAN interface and LAN interface(s) to advertise itself as a
   router to neighbors in the Service Provider and home networks.

You mean it sends RAs on the WAN side? Why???

   If the CPE Router has only one /64 prefix to be used across multiple
   LAN interfaces and the CPE Router supports any two LAN interfaces
   that cannot bridge data between them because the two interfaces have
   disparate MAC layer, then the CPE Router MUST support ND Proxy
   [RFC4389].

No, This will just be used as a reason for ISPs to give users less  
than a /64. If they do that, simply configure 1 LAN interface, no  
special case handling.

"Legacy 3GPP networks have the following requirements:"

I think it would serve the document better to keep such unusual cases  
out of it.

   For these legacy 3GPP networks, the CPE Router MUST support ND Proxy
   between the WAN and LAN interface(s).  However, if the CPE Router  
has
   multiple prefixes available for use on LAN interfaces(s), then ND
   Proxy is not necessary.

First a MUST and then "not necessary" is far from ideal specification  
writing...

About multicast: what happens on wifi, which can't handle non-minimal  
amounts of multicast traffic? (Also see the multicast discussion on  
the homegate list.)

   If the CPE Router hardware includes a network bridge between the WAN
   interface and the LAN interface(s), then the CPE Router MUST support
   MLDv2 snooping as per [RFC4541].

Can't it just treat multicasts as broadcasts? That's why cheap  
switches do AFAIK. I would rather not have MLD snooping, because if  
implemented incorrectly it breaks the network in severe ways. (Like  
boxes that didn't pass IPv6 multicasts because of IGMP snooping.)

"8.1. Path MTU Discovery Support (MEDIUM)"

Why medium? This is absolutely essential to avoid PMTUD black holes,  
one of the scurges of today's internet in general and the IPv6  
internet in particular. The language here MUST be much sharper.

"Ethernet Jumbo frames (9000+ bytes)"

Jumboframes is anything bigger than 1500 bytes.

   The CPE Router may support RIPng routing protocol [RFC2080] so that
   RIPng operates between the CPE Router and the Service Provider
   network.

Have you talked to ISPs about this? Not only is RIP slow, it's also  
insecure. I don't think they want this headache. And what if the ISP  
redistributes 50000 prefixes from other customers to the CPE?

Besides, "MAY" is useless. If 99 CPE vendors support RIP and 1 doesn't  
then the ISPs still can't use it.

"The firewall may"

Again, "may" language is useless. There must be a list of the  
extension headers that firewalls must support.

"CPE Router MAY initiate ISATAP"

How would that work??

   softwires.  Further, any approach which requires the use of a tunnel
   MUST take into account the reduced MTU.

Would be useful to include an MTU option in RAs that reflects the  
usable maximum packet size on the WAN side.

"An AAAA record is relayed to the server."

This sentence doesn't make any sense.

Please refer to the DNS64 document, a CPE either needs to do it right  
or not do it at all.