Subject: draft-wbeebee-ipv6-cpe-router-03

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Nov 2008 12:11:56 -0600

I think an important question is how firm we want to be on the issue  
of cascading CPEs.

With IPv4, you can nest/cascade CPEs that do NAT, which makes life  
harder on NAT traversal protocols but otherwise works without trouble.  
Because with IPv6, each CPE needs a prefix for its LAN interface(s)  
cascading CPEs without some kind of support from the ISP and upstream  
CPEs isn't possible. Basically, what needs to happen is that the first  
CPE gets a prefix from the ISP, and then implement a DHCPv6 server  
that delegates smaller prefixes to downstream CPEs.

The first CPE can't simply relay the request to the ISP, because even  
if we can presume the ISP to be generous and give more than one prefix  
to a single subscriber, the first CPE needs to install this prefix in  
its routing table. So that would require extensive DHCP relaying  
logic. So the situation where the CPE acts as a DHCPv6 server makes  
more sense. (Note that in the case where the cascading happens, we  
would also want the upstream CPE to disable its firewall for addresses  
in the delegated prefix to avoid double firewalling.)

Now I could see how vendors (especially of cheap) CPEs may not want to  
implement all of this. But in the case where such a CPE is provided by  
a broadband ISP and has a non-ethernet WAN port, the end-user would be  
unable to buy a premium CPE and be stuck with whatever suboptimal  
features the ISP-provided CPE incorporates. This is bad for everyone.  
The situation where the customer can go out and buy a better CPE is  
good for:

- the CPE vendors: more CPEs sold
- the ISPs: the ISP-provided CPEs don't have to be all things to all  
people
- the consumers: choice

So in the case that a CPE vendor doesn't want to implement the DHCPv6  
server necessary for cascading, I think we should mandate that the  
first CPE, when it detects that a secondary CPE is connected on the  
LAN side, becomes a transparent bridge. (Insert DHCPv6 option to make  
this happen.)

Unfortunately, this mode of operation would be incompatible with  
additional requirements for address assignment/registration and the  
use of a single, known good MAC address that broadband ISPs may  
impose. So I guess when those requirements are present, we're back  
with requiring a DHCPv6 server in the CPE.

Implementing a DHCPv6 server in the CPE rather than relaying DHCPv6  
requests to the ISP also reduces the amount of DHCPv6 traffic seen by  
the ISPs, which could be helpful.

Is the above something we can agree on?

Here are some more detailed comments on the draft:

You point to the IPv6 node requirements. I thought that router  
requirements would be more appropriate, but although there is an IPv4  
router requirements document penned by our esteemed chair, there is no  
such document for IPv6...

       mDNS - Multicast Domain Name System - see http:// 
www.zeroconf.org.

There's a bunch of multicast DNS related drafts floating around, maybe  
you can link to the most relevant one of those?

    If stateful DHCPv6 is not used to obtain other
    IPv6 configuration, then stateless DHCPv6 [RFC3736] must be  
initiated
    by the WAN interface to obtain other IPv6 configuration.

must or MUST?

I don't think there is any reason to use statless DHCPv6, because the  
router must always do stateful DHCPv6 to obtain a prefix anyway. It  
would be extremely unlikely that the server wouldn't return other info  
such as DNS addresses statefully but then provide this information if  
queried again statelessly.

BTW, what happens if the prefix delegation request fails and there is  
no prefix?

5.3.3.  Both Models

    At any instance in time of the CPE Router operation, the router does
    not forward any traffic between its WAN and LAN interface(s) if the
    router has not completed IPv6 provisioning process that involves the
    acquisition of a global IPv6 address by the WAN or if the WAN is
    unnumbered and there is no GUA available to source WAN packets.

A router generally doesn't source packets itself, so the presence of a  
WAN address doesn't really impact the router functionality...

    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; the O-bit is also set so that the CPE Router can pass
    Domain Name Server(s) IPv6 address(es) to home devices.  The CPE
    Router obtained the Domain Name Server(s) in OPTION_DNS_SERVERS
    option from the DHCPv6 server when the CPE Router WAN interface
    completed DHCPv6.

It would be good if CPEs would also insert DNS addresses in RAs as per  
RFC 5006. If requiring the support of an experimental RFC is a bridge  
too far, at the very least say this is a good idea and point to 5006.

It would be useful to tell people to align the timers in RAs with  
those in the PD delegation for easier renumbering. Note that during  
renumbering hosts may source packets with the old addresses even  
though the new ones are already available. This shouldn't cause  
trouble, but in cases where routes or filter rules are created,  
multiple sets of these are necessary during transition from one prefix  
to another.

For the purpose of shim6 support: it would be possible for a user to  
get service from two different ISPs and then hook up a third CPE to  
the two connected to these ISPs. This third CPE would then get a  
subdelegated prefix from each ISP. So either this CPE should support  
this, and use two prefixes at the same time, and send packets with  
source addresses from ISP A to the CPE that gave out addresses from  
ISP A, and packets with B addresses to the B CPE, or it should only  
accept one prefix and then make sure that all packets go to the router  
that delegated that prefix.

8.1.  Path MTU Discovery Support

When the WAN MTU is less than 1500 (such as in the case of PPPoE), the  
router should put the WAN MTU in the RA MTU option on the LAN side so  
the hosts use the reduced MTU and adjust their TCP MSS accordingly,  
reducing the likelihood of trouble because of PMTUD black holes.

8.2.  Optional RIPng Support

Is this useful?

8.3.  Firewall

There must be a way for the user to disable the firewall if desired.

These CPEs will be dual stack but they may be connected to an IPv4- 
only or even IPv6-only network. (Intentionally or by mistake, maybe  
one protocol has failed but the other still works, we certainly don't  
want fait sharing here...)

In the case where IPv4 is non-functional, a router MAY still advertise  
private addresses, which can be used for configuration or DNS lookups  
(if the CPE is a DNS forwarder, useful in the case of OSes that can't  
do DNS over IPv6 transport (Windows XP) or have no autoconfiguration  
of IPv6 DNS addresses (MacOS)) but MUST NOT provide a default gateway  
so that the hosts know they can't send packets towards IPv4  
destinations so long timeouts are avoided.

In the case of non-functional IPv6 but working IPv4, it's probably  
best to not let hosts autoconfigure addresses and also not have RAs  
create default gateways, because some OSes take the former to mean  
that there is working IPv6 and others the latter.

Please let me know what of the above is non-controversial and I'll  
submit text, if desired.

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 18 Nov 2008 10:37:51 -1000 (HST)

On Tue, 18 Nov 2008, Iljitsch van Beijnum wrote:

> So in the case that a CPE vendor doesn't want to implement the DHCPv6 server 
> necessary for cascading, I think we should mandate that the first CPE, when 
> it detects that a secondary CPE is connected on the LAN side, becomes a 
> transparent bridge. (Insert DHCPv6 option to make this happen.)

I'd prefer that each CPE router default to sub-delegating a fraction 
(user-configurable but with reasonable defaults) of the prefix delegated 
from it's 'upstream' CPE router.  The fraction would determine how many 
levels of nesting are possible and how large the downstream CPE fan-out is 
at each nesting level.  This might be more scalable since it means more 
consistent CPE behaviour regardless of whether it's the first downstream 
CPE router or the last.  One problem though is how does a CPE know when to 
actually delegate/reserve prefixes to a connected device which may or may 
not be a router.

> In the case of non-functional IPv6 but working IPv4, it's probably best to 
> not let hosts autoconfigure addresses and also not have RAs create default 
> gateways, because some OSes take the former to mean that there is working 
> IPv6 and others the latter.

How about auto-enabling 6to4 assuming it can actually reach a 
192.88.99l.1 gateway?

Antonio Querubin
whois:  AQ7-ARIN

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2008 10:06:59 +1300

On 2008-11-19 09:37, Antonio Querubin wrote:
...
> How about auto-enabling 6to4 assuming it can actually reach a

That doesn't guarantee connectivity; you actually need to see an
IPv6 reply before you know that 6to4 is working. So you really
need to enable 6to4, run a reachability test, and disable it if
no response.

    Brian

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 19 Nov 2008 00:32:00 +0200

On Tuesday 18 November 2008 22:37:51 Antonio Querubin, you wrote:
> > In the case of non-functional IPv6 but working IPv4, it's probably best
> > to not let hosts autoconfigure addresses and also not have RAs create
> > default gateways, because some OSes take the former to mean that there is
> > working IPv6 and others the latter.
>

How do you measure that? How do you know that there is no stateful firewall in 
front of your public IPv4 address?

I suspect broken automagic 6to4 gatewaying is the single most common reason 
for broken IPv6 connectivity in the real world right now.

-- 
Rémi Denis-Courmont

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 19 Nov 2008 00:35:08 +0200

> need to enable 6to4, run a reachability test, and disable it if

Even then. It might be working... until the stateful firewall expires your 
proto-41 pinhole. Here comes the 6to4 blackhole.

-- 
Rémi Denis-Courmont

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2008 08:35:02 +0200 (EET)

> need to enable 6to4, run a reachability test, and disable it if

Well, while this is one possible approach, and it may be the simplest 
test from a human perspective, an implementation could do a test 
without enabling 6to4.

You just need to craft a packet using a raw socket that resembles that 
kind of 6to4 packet, and watch for replies.  As an example of how 
Microsoft has done it, the implementation sends a proto-41 packet with 
IPv6 TTL=1 to an IPv6 address corresponding relay's v4 address, so the 
relay will return _something_ if connectivity at least up to the relay 
is working, the relay has v6 enabled, etc.

Live example from a relay:

08:31:01.202671 IP (tos 0x0, ttl 119, id 174, offset 0, flags [none], proto IPv6 (41), length 68) 93.106.184.x > 192.88.99.1: IP6 (hlim 1, next-header ICMPv6 (58) payload length: 8) 2002:5d6a:b8xx::5d6a:b8xx > 2002:c058:6301::c058:6301: [icmp6 sum ok] ICMP6, echo request, length 8, seq 2
08:31:01.202752 IP (tos 0x0, ttl 40, id 32297, offset 0, flags [none], proto IPv6 (41), length 116) 192.88.99.1 > 93.106.184.x: IP6 (hlim 64, next-header ICMPv6 (58) payload length: 56) 2002:c058:6301::1741 > 2002:5d6a:b8xx::5d6a:b8xx: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 56 for 2002:c058:6301::c058:6301

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 11:41:47 +0100

Dear all,

I am following the different mails exchanges from the beginning on the IPv6 CPE document but never contributed.  I would like to make a comment on the following proposals
---------------------------------------
" It would be good if CPEs would also insert DNS addresses in RAs as per RFC 5006. If requiring the support of an experimental RFC is a bridge too far, at the very least say this is a good idea and point to 5006."
---------------------------------------

Moreover some mail exchanges also occurs with proposal made by Tony Hain. See the mail below.
---------------------------------------
De : [email-masked] [mailto:[email-masked]] De la part de Brian E Carpenter Envoyé : lundi 17 novembre 2008 04:07 À : [email-masked] Cc : [email-masked]; 'Brian Haberman'; [email-masked] Objet : Re: Node Requirement: New issue 5: Support for RFC 5006
Has anyone reported implementation experience with 5006?
If so, we could discuss reclassifying it IMHO. But perhaps we should separate that question from progressing the node-req update.
   Brian
On 2008-11-16 07:39, Tony Hain wrote:
> The experimental designation is just wrong. We have to break the 
> current requirement to deploy both RA & DHCP if you want to have a working network.
> Each model should be able to stand on its own, and 5006 fills a hole 
> on that side. The 'experiment' is simply there to placate those that 
> want a DHCP-only model. Change the status of the RFC & make it a node 
> requirement...
> 
> Tony
---------------------------------------

I am seconding this proposal in order to support also a simpler model as an alternative to a local DHCPv6 server. 
The minimum set of requirements for an end device to communicate is to get its IP address, DNS server address and default gateway address. 
Assuming that some end devices could later discover its autoconfiguration server in the Broad Band Forum terminology, via initial factory provisionning or some automatic process, RFC5006 support is more that enough in the home gateway to reach this goal in this model. We could then avoid the use of a local DHCP server in the CPE for complex provisionning which has also the drawback of linking service evolutions and CPE evolutions. 
Even if support of RFC5006 is very poor in end devices with the exception of latest linux distributions and apart the fact that RFC5006 is experimental, it is a problem of chicken and egg. If not supported in end devices then we do not want it in the CPE and vice et versa. Including it in the CPE is a way/opportunity to move forward and propose an alternative to the DHCP model. 

Regards

JFC

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Iljitsch van Beijnum
Envoyé : mardi 18 novembre 2008 19:12
À : v6ops Operations
Objet : draft-wbeebee-ipv6-cpe-router-03

[...]

It would be good if CPEs would also insert DNS addresses in RAs as per RFC 5006. If requiring the support of an experimental RFC is a bridge too far, at the very least say this is a good idea and point to 5006.

It would be useful to tell people to align the timers in RAs with those in the PD delegation for easier renumbering. Note that during renumbering hosts may source packets with the old addresses even though the new ones are already available. This shouldn't cause trouble, but in cases where routes or filter rules are created, multiple sets of these are necessary during transition from one prefix to another.

[...]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2008 11:41:55 +1300

Pekka,

On 2008-11-19 19:35, Pekka Savola wrote:
> test from a human perspective, an implementation could do a test without
> enabling 6to4.
> 

Sure, but it is not sure that the 6to4 path is symmetric - the
reply packets might come from a completely different relay.

   Brian

> 08:31:01.202671 IP (tos 0x0, ttl 119, id 174, offset 0, flags [none],
> proto IPv6 (41), length 68) 93.106.184.x > 192.88.99.1: IP6 (hlim 1,
> next-header ICMPv6 (58) payload length: 8) 2002:5d6a:b8xx::5d6a:b8xx >
> 2002:c058:6301::c058:6301: [icmp6 sum ok] ICMP6, echo request, length 8,
> seq 2
> 08:31:01.202752 IP (tos 0x0, ttl 40, id 32297, offset 0, flags [none],
> proto IPv6 (41), length 116) 192.88.99.1 > 93.106.184.x: IP6 (hlim 64,
> next-header ICMPv6 (58) payload length: 56) 2002:c058:6301::1741 >
> 2002:5d6a:b8xx::5d6a:b8xx: [icmp6 sum ok] ICMP6, time exceeded
> in-transit, length 56 for 2002:c058:6301::c058:6301
>

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Nov 2008 17:11:15 -0600

> reply packets might come from a completely different relay.

It's impossible to test all the possible reverse paths that might ever  
be used, but a test to see whether the node at the 6to4 anycast  
address is actually a router running a functioning 6to4 relay is a  
worthwhile test for a CPE router to perform.

I don't think it's strictly necessary to shut down all IPv6 routing  
just because the anycast 6to4 relay isn't responding, because you can  
still reach all the other 6to4 sites over encapsulated direct IPv4,  
but it's certainly an exception condition worthy of asynchronous  
notification to a network manager... however that's done in the  
residential CPE environment.  (Apple has a proprietary method for  
doing that, but one could imagine specifying an SNMP trap message, for  
example.)

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering