Subject: [homenet] DHCP PD for homenets.

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 15:46:23 +0000

I don't have a particular preference for DHCP-PD over OSPF in homenets, but I just wanted to quickly contradict what's been said by several people at the mic: that figuring out what prefix to delegate is hard.   It's not hard, actually—it's dead easy.   The reason folks think it's hard is because they're solving the wrong problem.

The problem that needs to be solved is how we number each home subnet.   The answer to this question is, "with a /64."   There is no other answer.   You never want to number a subnet with a /52.   Therefore, the delegating router should never delegate anything but a /64.   Problem solved.

I think the disconnect here is that people are thinking the routers to which prefixes are delegated need to themselves be delegating routers, but this is incorrect.   What they need to do is _relay_ prefix delegation requests to the delegating router from which they got their own delegation.

This scales to multi-homing with multiple delegating routers—you just relay every PD request upstream to all delegating routers.

I'd be happy to write a draft that describes how this works if someone actually wants it; I get the sense that people are pretty in love with the OSPF solution and would prefer not to be distracted, and I have no argument with that if that's the working group consensus.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Nov 2012 10:53:05 -0500

> This scales to multi-homing with multiple delegating routers—you just relay every PD request upstream to all delegating routers.

+1; see my e-mail that passed this e-mail in flight.

> 
> I'd be happy to write a draft that describes how this works

draft-baker-homenet-prefix-assignment-01

> if someone actually wants it; I get the sense that people are pretty in love with the OSPF solution and would prefer not to be distracted, and I have no argument with that if that's the working group consensus.

- Ralph

> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ole Trøan <[email-masked]>
Date: Wed, 7 Nov 2012 10:59:28 -0500

Ted,

this has been proposed a few times. the problems that I see with it are:
 - in an arbitrary topology how do you decide which interfaces you are a client on and which interfaces you relay on
 - how do you handle the case where multiple routers try to assign a prefix to a link
 - how do you discover the DHCPv6 servers
 - how do you handle the case with multiple sources of information (multi-homing)

the OSPF based prefix assignment handle all of these, "out of the starting blocks".

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Wed, 7 Nov 2012 11:14:51 -0500

Ted,

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 11:23:39 -0500

> - in an arbitrary topology how do you decide which interfaces you are a client on and which interfaces you relay on

If you got a /64, you are not a delegating router for that prefix.

> - how do you handle the case where multiple routers try to assign a prefix to a link

Take them all.

> - how do you discover the DHCPv6 servers

The same way you always do—by multicasting a solicit.

> - how do you handle the case with multiple sources of information (multi-homing)

As above, for each delegated prefix, either act as a delegating router for it or not, depending on whether it is a /64 or larger.

---

From: Simon Kelley <[email-masked]>
Date: Wed, 07 Nov 2012 18:03:52 +0000

On 07/11/12 15:46, Ted Lemon wrote:

> I think the disconnect here is that people are thinking the routers
> to which prefixes are delegated need to themselves be delegating
> routers, but this is incorrect.   What they need to do is _relay_
> prefix delegation requests to the delegating router from which they
> got their own delegation.
>

... and once the delegating routers are relaying DHCP-PD requests, they 
can also relay DHCP address-lease requests to the DHCP server in the CPE 
router. This puts all the information about DHCP leases and associated 
names in one place, and greatly simplifies the naming problem.

Simon.

---

From: Ole Trøan <[email-masked]>
Date: Wed, 7 Nov 2012 13:19:38 -0500

Ted,

> I'm under the impression that a number of issues you mentioned as solved by OSPF and not solved by PD are actually not solved by OSPF.   To respond individually:

which ones?

> If you got a /64, you are not a delegating router for that prefix.

I can't grok your reply. how does a CPE determine which interface to relay on and which one to be a client on?
or does it do both?

>> - how do you handle the case where multiple routers try to assign a prefix to a link

it is a wanted property of the mechanism to have only one prefix per link.

> The same way you always do—by multicasting a solicit.

there are multiple DHCPv6 servers, aka sources of information in the network.
how does a CPE build the tree of relays to get to all the servers?
or are you suggesting that multicast routing is required in the home network?

> As above, for each delegated prefix, either act as a delegating router for it or not, depending on whether it is a /64 or larger.

can't grok this.
to ask this another way. how does DHCPv6 work with multiple servers having different information?
that's what a flooding solution solves elegantly, that a discover - request/reply protocol doesn't.

cheers,
Ole

---

From: David Lamparter <[email-masked]>
Date: Wed, 7 Nov 2012 13:21:26 -0500

> names in one place, and greatly simplifies the naming problem.

This really falls apart when I'm using 2 ISPs with 2 exit routers.
a-k-a, "Where's up?"

-David

---

From: Simon Kelley <[email-masked]>
Date: Wed, 07 Nov 2012 18:29:54 +0000

> This really falls apart when I'm using 2 ISPs with 2 exit routers.

and be put back together by noting that 2 exit routers doesn't have to 
mean 2 DHCPv6 servers. A single DHCP server can take PDs from 2 or more 
upstream ISPs. If the problem is that exit routers come with DHCPv6 
servers, then adding the ability to disable all but one (automatically 
or manually) would be worth considering.

Simon.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 7 Nov 2012 19:36:27 +0100 (CET)

> This really falls apart when I'm using 2 ISPs with 2 exit routers. 

I believe source based routing is needed somewhere.

Either it's done between the ISP routers and that's it, or we expand the 
standards so all routers in the home understands this.

ISP1 router says it's the default router for ISP1 PD prefix, ISP2 router 
says it's the default router for ISP2 PD prefix, and then they understand 
each other and if one happens to get traffic sourced from the others 
prefix, it's now properly forwarded to that ISP CPE.

I remember the discussion from a year ago, hasn't anything progressed 
since that? Hm, that might have been in v6ops though.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: David Lamparter <[email-masked]>
Date: Wed, 7 Nov 2012 13:45:10 -0500

> or manually) would be worth considering.

Yes, and now we need some protocol to decide which of the routers serves
as DHCPv6/PD server, that needs to work while crossing intermediate
routers possibly... (assuming we want to do it automatically)

So that's heading for another information propagation/flooding/election
protocol, at which point I don't see why we shouldn't just use OSPFv3.

-David

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 19:54:09 +0100

On Nov 7, 2012, at 7:21 PM, David Lamparter <[email-masked]> wrote:=
> a-k-a, "Where's up?

Why does it fail?   The system I described will wind up relaying to both delegating routers.

---

From: David Lamparter <[email-masked]>
Date: Wed, 7 Nov 2012 14:00:11 -0500

> Why does it fail?   The system I described will wind up relaying to both delegating routers.

I was only saying that this doesn't create a central point for naming
information,  not that it wouldn't work at all.

As I've said in my other mail, you end up going back to some election
mechanism, and from there it's easier to just stick with OSPFv3 (and
apply the nicer solutions provided by that across all areas) instead of
creating a new protocol.

-David

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 20:08:11 +0100

> apply the nicer solutions provided by that across all areas) instead of

Just to be clear here, my original point was never that we should switch and use DHCP PD within the homenet.   It was simply that DHCP PD would work for delegating prefixes in the homenet, and that the sub-delegation problem isn't actually a problem.   If OSPF in fact solves the name aggregation problem, that's great, but I don't think it's quite and cut and dried as you are saying, and so I wanted to make sure that the limitations of DHCP PD were not being misunderstood.

I suspect that there might be some value in a combination of DHCP PD and OSPF, but if OSPF really delivers all the functionality of DHCP PD, then maybe I'm wrong.

---

From: Teco Boot <[email-masked]>
Date: Wed, 7 Nov 2012 20:50:23 +0100

This should be in the homenet-arch, I think.

It sounds so obvious to me, that I described this in a short text in BRDP:
   A Router should request a prefix for attached subnetworks, with
   DHCP-PD [RFC3633], where there is at that moment no on-link prefix
   for a selected Border Router.

I could make the should a MUST.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 7 Nov 2012 20:54:06 +0100

> the OSPF based prefix assignment handle all of these, "out of the starting blocks".
It has little to do with OSPF. It is about the flooded TLV with info on border routers. BRDP does exactly the same here. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 7 Nov 2012 21:01:49 +0100

Op 7 nov. 2012, om 19:29 heeft Simon Kelley het volgende geschreven:

> and be put back together by noting that 2 exit routers doesn't have to mean 2 DHCPv6 servers. A single DHCP server can take PDs from 2 or more upstream ISPs. If the problem is that exit routers come with DHCPv6 servers, then adding the ability to disable all but one (automatically or manually) would be worth considering.

Multi-homing could be used for redundancy. Having a single DHCP server would not be the preferred choice here. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 00:14:21 +0100

Op 7 nov. 2012, om 23:33 heeft Ole Troan (otroan) het volgende geschreven:

> 
> 
> On 7 Nov 2012, at 14:50, "Teco Boot" <[email-masked]> wrote:
> 
> Disagree. Hierarchical or flat PD (with relays) don't work for multihomed sites, have problems with arbitrary topplogies etc. 

I do not suggest hierarchical PD, nor flat PD with relays. Leaves open flat PD without relay. Can you explain why this doesn't work?

My thoughts were driving me to a more manageable situation, where the CPE router manages all delegated prefixes for that ISP. CPE router can be multi-homed, then the task is for each ISP. HW for deterministic prefix configuration can be implemented on CPE router, or somewhere on ISPs network.
For ULA, one router is to be elected as "homenet manager". Here, a more distributed approach could make sense. Still I think management of such is unneeded complex and adds unneeded HW requirements on all routers (need for non-volatile memory, for deterministic behavior).

Related topic: IMHO non-CPE routers need a configuration for relaying DHCP requests to the CPE routers. PD from CPE router doesn't add complexity.

Teco  

> Cheers,
>>> I don't have a particular preference for DHCP-PD over OSPF in homenets, but I just wanted to quickly contradict what's been said by several people at the mic: that figuring out what prefix to delegate is hard.   It's not hard, actually―it's dead easy.   The reason folks think it's hard is because they're solving the wrong problem.
>>> 
>>> This scales to multi-homing with multiple delegating routers―you just relay every PD request upstream to all delegating routers.
>>>

---

From: "Ole Troan (otroan)" <[email-masked]>
Date: Wed, 7 Nov 2012 22:33:47 +0000

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Nov 2012 21:03:09 -0500

> Disagree. Hierarchical or flat PD (with relays) don't work for multihomed sites, have problems with arbitrary topplogies etc. 

You said this before, but you didn't describe any arbitrary topology in which PD wouldn't work.   Could you do that, please?

To be clear, although a PD topology is always hierarchical with respect to the relationship between any given requesting router and its delegating router(s), this does not mean that the topology of the homenet is a  hierarchy.

Let me give you an example.   Suppose you have a CPE router, A, at the customer edge.   And you have two homenet routers, B and C, each with an interface connected to A.   And you have a fourth homenet router, D, with an interface connected to B and one connected to C (I'm assuming direct twisted-pair ethernet links for simplicity).

I think you are supposing that because D has two paths to A, it will appear twice in the PD topology, even though it exists only once.   But that is not so.   It is only attempting to configure one interface—its downstream interface.   So the DUID and IAID will be the same in both copies of the DHCP solicit that A gets.   And so A will assign a single prefix, not two.

Suppose D is also a edge router.   We are now multihomed; A will be a requesting router with respect to D for the prefix that D got from its ISP; D will still be a requesting router with respect to A for the prefix that A got from its ISP.   The relationships between B and C and A, and between B and C and D, are likewise straightforward.

I can diagram this out for you if you want, but hopefully that illustrates the point I'm making.   Are you thinking of an even more contorted topology than this one?

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 04:24:06 +0100

> I think you are supposing that because D has two paths to A, it will appear twice in the PD topology, even though it exists only once.   But that is not so.   It is only attempting to configure one…

I would say that in case D doesn't have an additional interface, it doesn't request a prefix. It just autoconfigures one global address, although it may configure addresses on both links (to B and C).
And I suggest that if D requests a prefix, for an additional interface, it uses unicast to A, with an autoconfigured address. So A receives only one request.

Teco

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 8 Nov 2012 09:40:49 +0100

Well, I've not followed all of the homenet discussions on this PD-story, but I see a lot of referral to OSPF (v3), so it seems to be assumed that all these CPEs must "talk" OSPF ?
I think lots of them in the field today are low-end, low memory devices, hence probably 1. no OSPF will be present and 2. Calculating SP might put quite some pressure on its capabilities, no ?

I might be wrong on this one, so please disregard if this comment is not applicable.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: woensdag 7 november 2012 20:08
To: David Lamparter
Cc: Simon Kelley; [email-masked]
Subject: Re: [homenet] DHCP PD for homenets.

On Nov 7, 2012, at 8:00 PM, David Lamparter <[email-masked]> wrote:
> apply the nicer solutions provided by that across all areas) instead 
> of creating a new protocol.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 10:50:35 +0100 (CET)

On Thu, 8 Nov 2012, Wuyts Carl wrote:

> I think lots of them in the field today are low-end, low memory devices, 
> hence probably 1. no OSPF will be present and 2. Calculating SP might 
> put quite some pressure on its capabilities, no ?

We're talking tens or at max, hundreds of routes (/56 means 256 routes, 
times a few ISPs). This worked on hardware deployed in the field in the 
middle of 90ties, shouldn't devices produced today (or tomorrow) be able 
to do the same thing?

I don't see current devices being able to be sw upgraded to handle the 
demands we're talking about here anyway.

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 8 Nov 2012 12:45:30 +0100

Well, indeed things have been running for a long time, even in the 90's, but (for some reason) in today's world, the CPE should be as low cost as possible, resulting in cheaper chipsets and restricted memory.  On top of the 90's content, they also now have to include lots of extra's like samba sharing etc, so hard to compare.

I'm not saying that it is not possible on today's hardware, I only say that most of the (residential devices at least) today, have no OSPF support included anyway.  Changing them might be an option, but contradicts a little with the fact that no-one wants to pay for it.  It's the same for IPv6-intro in fact.  Some CPE hardware must be replaced, but who will take the bill ??
It was already a discussion in this year's IPv6 world congress, still seems to be an issue as far as I can see.  Maybe the attitude might change due to homenet architecture, but not sure it will.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: donderdag 8 november 2012 10:51
To: Wuyts Carl
Cc: Simon Kelley; [email-masked]; Ted Lemon; David Lamparter
Subject: Re: [homenet] DHCP PD for homenets.

On Thu, 8 Nov 2012, Wuyts Carl wrote:

> I think lots of them in the field today are low-end, low memory 
> devices, hence probably 1. no OSPF will be present and 2. Calculating 
> SP might put quite some pressure on its capabilities, no ?

We're talking tens or at max, hundreds of routes (/56 means 256 routes, times a few ISPs). This worked on hardware deployed in the field in the middle of 90ties, shouldn't devices produced today (or tomorrow) be able to do the same thing?

I don't see current devices being able to be sw upgraded to handle the demands we're talking about here anyway.

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 12:57:11 +0100

> I don't see current devices being able to be sw upgraded to handle the demands we're talking about here anyway.

I hope I misunderstand. If current CPE router and WiFi AP cannot be upgraded to what we are talking about, we are on a dead end.

Teco

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 8 Nov 2012 13:01:08 +0100

Well, define "current".

The ones deployed today and last year or so probably will not have a problem getting upgraded, and as we're managed CPE, this is well under control.  But there is a massive number of CPE devices in the field today which are indeed not upgradable to an IP-capable firmware.

Regs
Carl

Teco

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 07:06:17 -0500

> And I suggest that if D requests a prefix, for an additional interface, it uses unicast to A, with an autoconfigured address. So A receives only one request.

No, it doesn't, because that's not what RFC3315 and RFC3633 say to do, and it would badly break them to specify this behavior.   There's no harm in the duplicate packet, so no reason to break the protocol to avoid it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 13:31:33 +0100 (CET)

On Thu, 8 Nov 2012, Teco Boot wrote:

> I hope I misunderstand. If current CPE router and WiFi AP cannot be 
> upgraded to what we are talking about, we are on a dead end.

I have zero illusion that any devices that have been purchased with 
minimum requirements for IPv4 only, giving the deal to whoever cuts the 
cost that last 10 cents, is going to be upgraded to do ANYTHING more than 
what was initially specified.

I am however fairly confident that any CPE that was purchased in a way 
that assured that future functionality could be brought in, or is a 
premium product, will be able to support OSPF as well.

Do you believe that we could even get DHCPv6-PD into such devices. I have 
been in contact with CPE manufacturers who make products that are actually 
mid-range, who say they do not have flash and memory to do what I feel is 
very basic IPv6 functionality.

I think we should aim higher do what's best in the long run, and then CPE 
manufacturers will adapt. Yes, these new CPEs might be USD5-10 more than 
current generation, initially, but as these requirements spread and more 
people/ISPs buy, it'll be the new lowest standard and cost will drop.

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 14:20:41 +0100

> No, it doesn't, because that's not what RFC3315 and RFC3633 say to do, and it would badly break them to specify this behavior.   There's no harm in the duplicate packet, so no reason to break the p…

I read 3315 different. Intro:
 Once the client has determined the address of a server, it may under
 some circumstances send messages directly to the server using
 unicast.
With BRDP, the client is informed of addresses of servers. It can decide which server to use. This is a *required* feature for better multi-homing support. 
I agree the actual mechanism needs to be spelled out, e.g. when client needs to add a Relay Agent option in its messages.

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 14:52:31 +0100

Op 8 nov. 2012, om 13:31 heeft Mikael Abrahamsson het volgende geschreven:

> I have zero illusion that any devices that have been purchased with minimum requirements for IPv4 only, giving the deal to whoever cuts the cost that last 10 cents, is going to be upgraded to do ANYTHING more than what was initially specified.
We cold turn IPv4 off.
Or turn off a feature in data plane, and stop address sharing :-) 

> 
> I am however fairly confident that any CPE that was purchased in a way that assured that future functionality could be brought in, or is a premium product, will be able to support OSPF as well.
Sure. 
OLSR runs quite well on old days CPE devices, 100ths of routers, 1000ths of links.

> 
> Do you believe that we could even get DHCPv6-PD into such devices.
Sure. What is the problem?

> I have been in contact with CPE manufacturers who make products that are actually mid-range, who say they do not have flash and memory to do what I feel is very basic IPv6 functionality.
I cannot response, other than that competition will make the products available for us.

> 
> I think we should aim higher do what's best in the long run, and then CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more than current generation, initially, but as these requirements spread and more people/ISPs buy, it'll be the new lowest standard and cost will drop.
If we drop IPv4, and have full Homenet compliancy, CPEs might be USD5-10 cheaper:-)

Teco

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 8 Nov 2012 09:47:48 -0500

>people/ISPs buy, it'll be the new lowest standard and cost will drop.

It's very generous of you to spend other people's money this way.

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 16:07:16 +0100 (CET)

On Thu, 8 Nov 2012, Howard, Lee wrote:

>> I think we should aim higher do what's best in the long run, and then 
>> CPE manufacturers will adapt. Yes, these new CPEs might be USD5-10 more 
>> than current generation, initially, but as these requirements spread 
>> and more people/ISPs buy, it'll be the new lowest standard and cost 
>> will drop.
>

What is your suggestion?

New requirements mean higher spec hw, I don't really see a way around 
that. Do you?

For ISPs who want to save those few dollars, they can offer NAT444 and 
then do not need to require more functionality in their CPEs. In the areas 
where customers have a choice, let them choose.

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 8 Nov 2012 10:44:09 -0500

>New requirements mean higher spec hw, I don't really see a way around

Stop solving non-existent problems in the most complex way possible.
Stop defining "what's best in the long run" as "support Jari and Mark's
infinitely complex home networks without configuration."

I've made this point to the WG several times.  Complexity leads to
unpredictability.

>where customers have a choice, let them choose.

Is anyone choosing the Homenet model?

Lee

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 8 Nov 2012 17:58:38 +0100 (CET)

> I've made this point to the WG several times.  Complexity leads to 

Could you please point me to where you have done this. I went back a year 
and read posts by you, and couldn't really find any such point (not a 
clear one anyway).

> Is anyone choosing the Homenet model?

Well, personally I work in a market where people have the option to choose 
between several ISPs, and competition is quite intense. We plan to offer 
/56 and we want customers who so choose, to choose us plus another ISP for 
redundancy. I see more and more people going for home automation and 
running into RFC1918 related trouble to access this from the outside, so I 
believe something along the lines of homenet is needed long-term to sort 
out this mess.

Perhaps it'll be more clear to me what you see as the homenet goal after I 
get the answer to my above question.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2012 14:36:17 -0500

> some circumstances send messages directly to the server using

The document then goes on to describe under what circumstances the client may unicast, and they do not include your use case.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 09 Nov 2012 15:03:17 -0800

On 11/08/2012 07:07 AM, Mikael Abrahamsson wrote:
> New requirements mean higher spec hw, I don't really see a way around that. Do you?
>
> For ISPs who want to save those few dollars, they can offer NAT444 and then do not need to require more functionality in their CPEs. In the areas where customers have a choice, let them choose.
>

Let's not forget that Moore's Law will make all of this rather irrelevant
by the time this is rolled out and widespread. We're talking realistically
years and years before this is mainstream.

Mike