Subject: [v6ops] CPE Prefix Sub-Delegation on LAN

From: <[email-masked]>
Date: Wed, 22 Dec 2010 17:06:01 +0100

Hello,

This mail is related to draft-wbeebee-v6ops-ipv6-cpe-router-bis. LAN Prefix Sub-Delegation is described as "To Be Defined".

In a few words, what is the mechanism that will be described in this draft? 
Is it planned to recommend only DHCPv6 PD ?
In that case, is there any work done somewhere in the IETF about how a DHCPv6 server should get the "master" prefix and prefix size (especially when it has to be extrapolated from 6rd) ?

I believe this is a blocking point for the home, in case of dynamic assignment from the ISP, because with the basic requirements, the number of /64 subnets is limited to the number of interfaces on the LAN side of the CPE. And the customer wouldn't be able to have any additional router at home. I've been browsing the list archives and meeting minutes so I understood that the group is already fully aware of the limitation (which I expected) but I couldn't find a clear solution. Or did I miss something ?

(by the way, a typo there I think : 5.5, R1, last line ("and" = "an" or "any"?): The CPE Router MAY support and IGP in the home network.)

Best regards,
Guillaume

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 22 Dec 2010 10:41:12 -0600

Guillaume,

Thanks for catching the typo.  Yes, indeed it should be "an" IGP.  The
LAN Prefix sub-delegation is still a TBD for this document and we are
under discussions with SPs and other folks for designing such a
mechanism.  One mechanism is of course, the DHCPv6 PD but details have
to be flushed out with such a mechanism for the routed home.

Regards,

Hemant  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, December 22, 2010 11:06 AM
To: [email-masked]
Subject: [v6ops] CPE Prefix Sub-Delegation on LAN

Hello,

This mail is related to draft-wbeebee-v6ops-ipv6-cpe-router-bis. LAN
Prefix Sub-Delegation is described as "To Be Defined".

In a few words, what is the mechanism that will be described in this
draft? 
Is it planned to recommend only DHCPv6 PD ?
In that case, is there any work done somewhere in the IETF about how a
DHCPv6 server should get the "master" prefix and prefix size (especially
when it has to be extrapolated from 6rd) ?

I believe this is a blocking point for the home, in case of dynamic
assignment from the ISP, because with the basic requirements, the number
of /64 subnets is limited to the number of interfaces on the LAN side of
the CPE. And the customer wouldn't be able to have any additional router
at home. I've been browsing the list archives and meeting minutes so I
understood that the group is already fully aware of the limitation
(which I expected) but I couldn't find a clear solution. Or did I miss
something ?

(by the way, a typo there I think : 5.5, R1, last line ("and" = "an" or
"any"?): The CPE Router MAY support and IGP in the home network.)

Best regards,
Guillaume
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Dec 2010 09:11:55 -0800

> In a few words, what is the mechanism that will be described in this draft? 

In the original draft, there was a discussion of how to achieve it, and the net result was an algorithmic description in a requirements document. As chair, I said then that we should ask 6man to specify a mechanism, and sent an internet draft summarizing one possible approach. 6man didn't comment. I still think the mechanism should be specified in a separate RFC, and this document should say "implement at least that".

One obvious approach would be, as you say, to have the routers within a network enquire of an DHCPv6 server in the CPE Router requesting subdelegation of its PD. There is an interesting problem there in terms of race conditions. If I have redundancy in the network, perhaps something like

                                      |              |
                                      |  +--------+  |
                                      +--+Interior+--+
                                      |  | Router |  |
                                      |  +--------+  |
                        +----------+  |              |
      Upstream  --------|CPE Router+--+              |
                        +----------+  |              |
                                      |  +--------+  |
                                      +--+Interior+--+
                                      |  | Router |  |
                                      |  +--------+  |
                                      |              |

I have a problem. The upstream obviously delegates a prefix to the CPE Router, perhaps a /60, and the CPE uses a /64 out of that for its own LAN. The interior routers will then hear its RA, and will form addresses on the indicated LAN. They will also determine what address their DHCPv6 server is at, perhaps from Stateless DHCP announcements; this obviously wants to be in the CPE Router. They will now each ask that process for a prefix for their LANs. Ideally, the DHCPv6 process will realize that they share a common LAN and give them the same prefix; at least the first time that happens, I don't know how it does that absent configuration. I suppose it could rate limit its responses - send at most one DHCPv6 PD response per second, enabling one of the interior routers to get its configuration together and give the other the opportunity to discover that it needs no such delegation. I can also think of problems with that in a best effort network. 

Having sketched a problem statement in this email, let me invite a draft from the working group. If it actually requires new technology, we should send a request to 6man or somewhere else to have it developed (says our charter), but if it is simply operational procedure I imagine we can do it ourselves. I don't care who offers the draft, but let's get at least one on the table to discuss.

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 19:27:12 +0100

> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, December 22, 2010 6:12 PM
> 
> One obvious approach would be, as you say, to have the routers within a
> network enquire of an DHCPv6 server in the CPE Router requesting
> subdelegation of its PD. There is an interesting problem there in terms
> of race conditions. If I have redundancy in the network, perhaps
> something like
> 
>                                       |              |
>                                       |  +--------+  |
>                                       +--+Interior+--+
>                                       |  | Router |  |
>                                       |  +--------+  |
>                         +----------+  |              |
> I have a problem. The upstream obviously delegates a prefix to the CPE
> Router, perhaps a /60, and the CPE uses a /64 out of that for its own
> LAN. The interior routers will then hear its RA, and will form
> addresses on the indicated LAN. They will also determine what address
> their DHCPv6 server is at, perhaps from Stateless DHCP announcements;
> this obviously wants to be in the CPE Router. They will now each ask
> that process for a prefix for their LANs. Ideally, the DHCPv6 process
> will realize that they share a common LAN and give them the same
> prefix; at least the first time that happens, I don't know how it does
> that absent configuration. I suppose it could rate limit its responses
> - send at most one DHCPv6 PD response per second, enabling one of the
> interior routers to get its configuration together and give the other
> the opportunity to discover that it needs no such delegation. I can
> also think of problems with that in a best effort network.

That's indeed an interesting problem. However, I don't see any bad consequences: end-hosts will have two working IPv6 addresses instead of one, and those IPv6 will be from different working prefixes with different working routers.

Everything else could be solved via configuration of the CPE, and I think we expect most of the users with this design to be able to log in to their CPE and configure a "cluster" or whatever it should be called. Especially when it comes to using this design for multi-homing the end hosts, then it has to be solved via configuration because no basic user will try to multi-home.

> Having sketched a problem statement in this email, let me invite a
> draft from the working group. If it actually requires new technology,
> we should send a request to 6man or somewhere else to have it developed
> (says our charter), but if it is simply operational procedure I imagine
> we can do it ourselves. I don't care who offers the draft, but let's
> get at least one on the table to discuss.

There might be some work to do to say how the dhcpv6 server in the CPE should get the prefix received from the ISP, also when the ISP is not using DHCPv6. For example, with 6rd. However, since the 6rd parameters have to be pre-provisioned or given via DHCP(v4), I can imagine that there's a way to sort this out without too much pain.

Guillaume

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 Dec 2010 13:06:23 +0100

[included the homenet list]

> There might be some work to do to say how the dhcpv6 server in the CPE should get the prefix received from the ISP, also when the ISP is not using DHCPv6. For example, with 6rd. However, since the…

with regards to 6rd, there is nothing special. a 6rd delegated prefix is just like an DHCP PD prefix, for the purpose of internal prefix assignment.

this problem within the charter of the (rejected) homenet WG effort.

there are many ways internal prefix assignment and distribution of other configuration information can be done. many of the ideas were discussed during the zerouter BOF (which also failed making it into a WG).

- Multi-link subnet routing (a shared off link /64 among all nodes. host routes in OSPF)
- ND proxy (restricted topology)
- hierarchical DHCP prefix delegation (restricted topology)
- zOSPF (https://datatracker.ietf.org/doc/draft-dimitri-zospf/)
  using a new LSA in OSPF to distribute the site prefix plus a mechanism for
  collision detection.

in my view this requires new work.

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 Dec 2010 23:12:40 +1030

On Thu, 23 Dec 2010 13:06:23 +0100

>   using a new LSA in OSPF to distribute the site prefix plus a mechanism for

Another possible addition to the list could be some of the mesh routing
protocols that have/are being developed for wireless and/or sensor
networks. As laptops have overtaken desktops in sales, and they usually
come with wired and wireless interfaces, it probably wouldn't be much
of an unacceptable burden for them to also act mesh routers.
They'll do more throughput and have faster CPUs than most routers that
would be present in most residential and SOHO environments.

Regards,
Mark.

---

From: Bruce Zamaere <[email-masked]>
Date: Thu, 23 Dec 2010 14:53:41 +0100

Guillaume,

This is an interesting discussion and I too would very much like to
see more work into this. Our current research is focused on developing
a robust multi-homed residential gateway that can facilitate the
delivery of home-based healthcare services. It would be 'nice' to have
different local subnets for different applications or services in this
case.

On Wed, Dec 22, 2010 at 7:27 PM, <[email-masked]> wrote:
>
> Everything else could be solved via configuration of the CPE, and I think
> we expect most of the users with this design to be able to log in to their CPE
> and configure a "cluster" or whatever it should be called. Especially when it
> comes to using this design for multi-homing the end hosts, then it has to be
> solved via configuration because no basic user will try to multi-home.

I don't have a solution up my sleeve but I believe it should be
possible to define mechanisms that would allow even "basic users" to
take advantage of multi-homing. This is an important consideration for
my research. In line with this, I am also interested in supporting
SCTP enabled endpoints. Now I haven't thought about this much, but
would it be possible for a CPE that has received prefixes from
multiple upstream ISPs to allocate IPs from each of these prefixes to
SCTP capable hosts?

regards,

/Bruce.