Subject: [homenet] draft-baker-homenet-prefix-assignment

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 15:44:22 +1300

Fred,

The mic line was too long to bring this up:

You suggest using RFC 3633. How about RFC 2894 (Router renumbering) too?

Typo: the draft actually cites RFC 3363, which is not what you intended...

-- 
Regards
   Brian Carpenter

---

From: Ralph Droms <[email-masked]>
Date: Tue, 15 Nov 2011 10:49:19 +0800

> You suggest using RFC 3633. How about RFC 2894 (Router renumbering) too?

What device controls the use of RFC 2894?  RFC 3633 triggers assignment from the routers that actually need the prefixes.

> Typo: the draft actually cites RFC 3363, which is not what you intended...

Oops.

- Ralph

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2011 10:52:13 +0800

> Typo: the draft actually cites RFC 3363, which is not what you intended...

Ditto on the mic line—very frustrating.   I think you overestimate the obstacles to using DHCPv6 PD for this application.   I don't think any protocol extension is required.   What is needed is ad-hoc relay configuration, which is already anticipated.   The CPE device can just allocate a /64 for any PD it receives, and with ad-hoc relaying, it should all Just Work.

The way ad hoc relaying works is that when you come up, your PD client asks for a prefix on its upstream port.   If it receives PDs, it relays them on its upstream port.   These PDs all wind up at the CPE device, which allocates /64s to them and forwards them back, all in accordance with the existing DHCP relay mechanism.

I think homenet would have to do a draft describing how to set this up, but it does not require a DHCP extension.   There'd be some details to document on how the routing topology gets set up; perhaps that could be done with OSPF.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 15 Nov 2011 10:55:53 +0800

> Ditto on the mic line—very frustrating.   I think you overestimate the obstacles to using DHCPv6 PD for this application.   I don't think any protocol extension is required.   What is needed is ad-…

Yup.  No protocol extensions needed to DHCPv6.  Needs some careful thinking about how to use RAs as the trigger for deciding when a prefix is needed.

> I think homenet would have to do a draft describing how to set this up, but it does not require a DHCP extension.   There'd be some details to document on how the routing topology gets set up; perh…

Also might need a little thinking about how to accommodate multi-homed networks; e.g., allow the requesting router to take a prefix from each of the delegating routers it hears from (as opposed to the address assignment strategy of choosing one DHCP server to interact with).

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 15:57:38 +1300

> What device controls the use of RFC 2894?  RFC 3633 triggers assignment from the routers that actually need the prefixes.

I would assume it has to be the CE router. But I have no problem if you say that
RFC 2894 is unnecessary; it was an unused solution that we identified in RFC 5887,
so it's in my mental list of loose ends.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Nov 2011 10:59:43 +0800

> You suggest using RFC 3633. How about RFC 2894 (Router renumbering) too?

It makes some "interesting" assumptions; I can point to one router vendor that has chosen to not implement it until some of the underlying assumptions get fixed.

> Typo: the draft actually cites RFC 3363, which is not what you intended...

oops...

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2011 11:00:32 +0800

> Also might need a little thinking about how to accommodate multi-homed networks; e.g., allow the requesting router to take a prefix from each of the delegating routers it hears from (as opposed to…

Yup, in my experience multihoming simply doesn't work on a variety of levels.   One of the ways in which it doesn't work is that the DHCP protocol doesn't really account for it.   We kind of assume that a single DHCP server will be responsible for all prefixes that are advertised on the wire.   We could come up with a way for two DHCP servers to elect a responsible server, or we could decide to expand DHCP to support multiple servers.   I suspect the former solution is easier than the latter.

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Nov 2011 11:08:11 +0800

> Ditto on the mic line—very frustrating.   I think you overestimate the obstacles to using DHCPv6 PD for this application.   I don't think any protocol extension is required.   What is needed is ad-…

It's comforting that you think I overestimate the issues. 

> The way ad hoc relaying works is that when you come up, your PD client asks for a prefix on its upstream port.   If it receives PDs, it relays them on its upstream port.   These PDs all wind up at…

Let me say something that will probably get me tarred and feathered. I suspect that if we come up with a good solution for the home, it will be used in small networks wherever they materialize. So I think of a home or SOHO as a special case of a small network. I could imagine, for example, a company that has lots of campuses and lots of buildings in each campus considering each campus or each building to be a "small network" and letting it use this class of procedure within itself.

"upstream port"? If I have a multihomed network with a CPE per upstream, and the "inside" interface on one CPE develops an address in a different CPE's prefix, is it "upstream" or "downstream" from that other CPE?

Yes, I know those words get printed on plastic my company sells. It think it's a pretty bad paradigm for anything I'd call scalable to anything but the tiniest domain. I would far rather generate a solution that can be used effectively within an arbitrary domain, such as a single area OSPF network, without being unnecessarily hobbled in its thinking. Anything that gives a router a direction is a rather strange hobble in that context.

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Nov 2011 11:17:39 +0800

Ted,

> I think homenet would have to do a draft describing how to set this up, but it does not require a DHCP extension.   There'd be some details to document on how the routing topology gets set up; perh…

- how do you discovery the DHCP server? do you require a hard-wired upstream port for this to work?
- what do you do with two routers on the same link, two separate prefixes? (or smart DHCP server (e.g. having the SPF))
- what do you with multiple sources of information? change the DHCP protocol so that a client picks _all_ servers, instead of
  the _best_ one?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2011 11:35:41 +0800

> - how do you discovery the DHCP server? do you require a hard-wired upstream port for this to work?

Multicast will reach the DHCP server.   Otherwise yes, the hard-wired upstream port allows this to work.

> - what do you do with two routers on the same link, two separate prefixes? (or smart DHCP server (e.g. having the SPF))

I don't know what you mean by a "smart DHCP server having SPF."   But if you have two routers on the same link, either the client picks one and doesn't get to use the other link, or the DHCP servers need to cooperate, or we need to teach the client to get prefix delegations from more than one DHCP server.   I think having the DHCP servers do an election is probably the easiest solution.

> - what do you with multiple sources of information? change the DHCP protocol so that a client picks _all_ servers, instead of the _best_ one?

Right now clients don't pick the best one--they just pick one pretty much at random.  But yes, if you have two DHCP servers providing different information, you need to resolve that.   We would have to write a spec to handle this—it's not handled in the existing protocol.

I think changing the DHCP client is a bad idea because it requires that every client be changed; changing the DHCP server is easy because only homenet DHCP servers have to change.

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 22:18:14 -0500

> Right now clients don't pick the best one--they just pick one pretty much at random.  But yes, if you have two DHCP servers providing different information, you need to resolve that.   We would hav…

We need to be aware that not every network may be able to reach the
Internet... So you might need to have an address from every available
DHCP server, not just the "best," one, or even a "random," one.

For instance, your computer might talk to the power company, but the
power company doesn't want to transit your internet traffic. I'm not
saying this is a certainty, only that we need to think about it somehow.

:-)

Russ

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 12:09:29 +0800

> DHCP server, not just the "best," one, or even a "random," one.

Yes, this is part of a problem space of which I have become keenly aware over the course of this IETF meeting.   Expect a draft shortly.   :)

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 13:52:51 +0800

> Yes, this is part of a problem space of which I have become keenly aware over the course of this IETF meeting.   Expect a draft shortly.   :)

do we need to?
in a self organizing unmanaged home; if we were to do a combination of a network wide flooding mechanism and RAs. would we need DHCP in the network at all?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 14:31:02 +0800

> in a self organizing unmanaged home; if we were to do a combination of a network wide flooding mechanism and RAs. would we need DHCP in the network at all?

I am not claiming that we do. However, the problem exists whether we do DHCP in homenet or not.

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 14:33:29 +0800

> I am not claiming that we do. However, the problem exists whether we do DHCP in homenet or not. 

yes, indeed.

cheers,
Ole

---

From: Randy Turner <[email-masked]>
Date: Tue, 15 Nov 2011 22:33:53 -0800

If you want to configure more than just layer-3 connectivity, seems like you would need *something* ...

Randy

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Nov 2011 14:42:04 +0800

>> Yes, this is part of a problem space of which I have become keenly aware over the course of this IETF meeting.   Expect a draft shortly.   :)

Need to what? Provide a subnet number on each subnet?

Is that a real question?

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 14:46:29 +0800

Fred,

> Need to what? Provide a subnet number on each subnet?

extend the DHCP protocol to handle multiple sources of information.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 14:56:44 +0800

> extend the DHCP protocol to handle multiple sources of information.

I think this winds up being implicit in MIF's charter, although I didn't realize that until quite recently.

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Nov 2011 15:41:27 +0800

I don't much care whose charter it's in. I do think that if we have an idea that an ISP will allocate an IA_PD to a directly attached router and that router will then, in some way, sub-allocate subnet prefixes to subnets in the home, then there is a case in which there are multiple ISPs that have separate routers doing that. Ralph and I have suggested using the same mechanism that ISPs use to allocate prefixes to the home to allocate prefixes within the home, which means having multiple DHCP servers. If we do it another way, whether ZOSPF's or some other way, we have the same problem in the sense that there will be multiple sources of subnet prefixes.

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 16 Nov 2011 15:56:15 +0800

On 11/16/11 15:41 , Fred Baker wrote:
> I don't much care whose charter it's in. I do think that if we have
> an idea that an ISP will allocate an IA_PD to a directly attached
> router and that router will then, in some way, sub-allocate subnet
> prefixes to subnets in the home, then there is a case in which there
> are multiple ISPs that have separate routers doing that. Ralph and I
> have suggested using the same mechanism that ISPs use to allocate
> prefixes to the home to allocate prefixes within the home, which
> means having multiple DHCP servers. 

which seems like a slightly more eleborate variation of having multiple
available routers or nexthops due to having multiple RAs.

If we do it another way, whether
> ZOSPF's or some other way, we have the same problem in the sense that
> there will be multiple sources of subnet prefixes.
> 
>> I think this winds up being implicit in MIF's charter, although I
>> didn't realize that until quite recently.
> 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 15:58:41 +0800

On Nov 16, 2011, at 3:41 PM, Fred Baker <[email-masked]> wrote:
> If we do it another way, whether ZOSPF's or some other way, we have the same problem in the sense that there will be multiple sources of subnet prefixes.

Yes.   This becomes an even uglier problem as you progress into the network, because while at the edge you can tell that you are talking to two administrative domains, as you move into the network past the first delegating router, you wind up with a single DHCP server presenting the merged configuration information from two administrative domains as if they were a single administrative domain.

I thought I understood how to solve this problem before I started writing the problem statement, and then when I remembered this aspect of it I kind of flung my hands up in disgust.   I think the knowledge that there are two separate administrative domains has to be visible throughout the network, but this is really a substantial divergence from what DHCPv6, at least, currently does.

I can certainly imagine extending DHCPv6 in a cascading prefix delegation scenario where it signals this information down the cascade, but it's conceptually quite a bit different.

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 16:12:32 +0800

Ted,

> I can certainly imagine extending DHCPv6 in a cascading prefix delegation scenario where it signals this information down the cascade, but it's conceptually quite a bit different.

that's exactly reasons why we have started looking at flooding type protocols in homenet as opposed to request/reply protocols.
it isn't only multiple sources and service discovery that is problematic with a request/reply protocol, it is also how it handles dynamism. something which was explored in the development of the DNS option for RA.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2011 16:24:26 +0800

> it isn't only multiple sources and service discovery that is problematic with a request/reply protocol, it is also how it handles dynamism. something which was explored in the development of the DN…

I think that flooding protocols are a good idea for discovering the topology of the homenet and setting up routing.   However, I suspect that you are going to get your prefix(es) from your provider(s) through DHCPv6 prefix delegation, so there's still a problem to be thought through.   I don't have a strong opinion yet on whether you should use PD inside of the network, although I think once you've discovered the network topology (which you could do with link-local addresses) it's certainly a viable mechanism.

---

From: Ole Troan <[email-masked]>
Date: Wed, 16 Nov 2011 18:04:53 +0800

Ray,

> Actually, if you use another mechanism within the home there's a danger that it might be worse: you then have potentially different semantics of leases and possibly a lack of synchronization of timers: the lease on the ISP link may expire, but locally assigned Homenet sub-leases not, leading to black holes. Might become significant when changing providers or when providers want to renumber.

you already have that. and from what I heard from UNH most CPEs got it wrong. (DHCPv6 PD lease timers must be mapped to RA PIO option life times).

cheers,
Ole

> Fred Baker wrote:
> Ray Hunter
> [email-masked]
> Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
> Registered at the KvK, Eindhoven, under number BV 17098279
> mobile: +31 620 363864
> 
> <Ray_Hunter.vcf>

---

From: Ray Hunter <[email-masked]>
Date: Wed, 16 Nov 2011 11:16:40 +0100

Sure you should cascade the IA_PD timers into the ND RA prefix 
information option lifetime timers. Doh. Wasn't that obvious? Just 
because people got it wrong once doesn't mean we should make things even 
more complex. In fact, that's all the more reason that Homenet should 
address implementation simplicity, and the interaction of timers explicitly.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Nov 2011 20:28:17 -0500

Is there some reason that the flooding mechanism can't distribute the
list of edge CPE routers, and then DHCPv6 can be used in unicast
request/reply to ask those CPE routers for things.

(I would even wonder if the CPE routers shouldn't be identified by their
ULA rather than self-identifying by the address in the subnet the deal with)

This is how I imagined the DHCPv6 PD mechanism working before
draft-chakrabarti-homenet-prefix-alloc-01 was written, which imagined a
strict hierarchal tree.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 09:14:12 +0100

Michael,

> draft-chakrabarti-homenet-prefix-alloc-01 was written, which imagined a

that's how I imagined also.
DHCP PD on the edges. flooding protocol between all the internal routers. then hosts use RA/DHCP for addresses / other configurations to their onlink routers.

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Nov 2011 13:38:33 -0500

>>>>> "Ole" == Ole Troan <[email-masked]> writes:
    >> Is there some reason that the flooding mechanism can't distribute
    >> the list of edge CPE routers, and then DHCPv6 can be used in
    >> unicast request/reply to ask those CPE routers for things.
    >> 
    >> (I would even wonder if the CPE routers shouldn't be identified
    >> by their ULA rather than self-identifying by the address in the
    >> subnet the deal with)
    >> 
    >> draft-chakrabarti-homenet-prefix-alloc-01 was written, which
    >> imagined a strict hierarchal tree.

    Ole> that's how I imagined also.  DHCP PD on the edges. flooding
    Ole> protocol between all the internal routers. then hosts use
    Ole> RA/DHCP for addresses / other configurations to their onlink
    Ole> routers.

so, does this mean we have to write another draft to explain it?