Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
Pierre, On 10/11/2014 16:33, Pierre Pfister wrote: > Thank you Brian for your review. > > See my answers inline. Thanks, I will just comment where there is something open: ... >>> Link ID: If the assignment is made on a connected link, an interface >>> identifier of the interface connected to that link. >> That's a bit confusing because a link is not an interface, and the same >> link connected to multiple interfaces will have multiple Link IDs >> by this definition. Also, you can't call it Interface ID because that >> has a specific meaning in IPv6. I don't have a good suggestion but >> it needs to be tidied up IMHO. > > I agree. But as ‘interface ID’ can’t be used, I wonder what could be best. There is the term 'Zone ID' used in RFC 4007 and 6874, but that is possibly even more confusing. However, it is what we have and there is even URL syntax for it. > ... >>> If an internal interface becomes external, all prefixes and addresses >>> assigned on the considered interface MUST be deleted... >> Yes but... they can't be dropped instantly; at least for v6 they have >> to go through the deprecation phase, surely? > > IMHO, they should be dropped instantly. > Because if you start considering a link as external, it means you realized > that you have absolutely no right to be a default router on that link. > At best, you do something that you shouldn’t do. At worst, the uplink router > may kill the port you are connected on. > > I agree I could clarify though. Yes, certainly if you "kill" an IPv6 address without going through normal deprecation that needs to be clearly stated. > >> ... >>> Whenever two or more interfaces are connected to the same link, >> How is this known to be the case? I imagine a little TV camera >> peeping out from the router to look at the cables… > > In the same paragraph: > A mechanism to detect such situation SHOULD be provided by the >flooding algorithm. > > Do you think I should rephrase somehow ? No, I have to read HNCP again soon and then I will be back if I don't understand. >>> 4.5. Designated Router >>> >>> On a link where custom host configuration must be provided, or >>> whenever SLAAC cannot be used, a DHCP server must be elected. That >>> router is called designated router and is dynamically chosen by the >>> prefix assignment algorithm. >> You are assuming without stating it that the DHCP server MUST be located >> in the same device as a router. Why? > > In a homenet context, I think it makes sense. > Doing it differently would probably increase the algorithm complexity. > Now, you’re probably suggesting that, in other scenarios, it may be different > ? > Do you have a use-case in mind so it would make sense to make it differently ? Not in a homenet, no, but this restriction will not apply in anima, I think. ... >>> 6.6. Making a New Assignment >> ... >>> When the algorithm decides to make a new assignment, it first needs >>> to specify the desired size of the assigned prefix. Although this >>> algorithm intends to remain generic, the use of 64 bits long prefixes >>> is RECOMMENDED (See [I-D.ietf-6man-why64]). >> And for v4? > > Hard to fulfill that recommandation with v4. ;) > > I found it pretty clear that it doesn’t apply to v4. But right. I will patch > that for next version. Right, do you want to specify a minimum size v4 subnet, or just leave it open? >>> 6.10. Downstream DHCPv6 Prefix Delegation support >> ... >> >>>If DHCPv6 Reconfigure is >>> not supported, leases lifetimes SHOULD be significantly small. >> Can't parse "significantly". Can you quantify this? > > 2h ? > Do you have a proposal ? Not really, I just think you should suggest a recommended value. ... >>> Additionaly, a router SHOULD start advertising its own ULA prefix >>> whenever the three following conditions are met: >>> >>> o A stable ULA prefix is advertised by another router. >>> >>> o The router owns the advertised stable ULA prefix. >> I got confused about which router is which. Could you give >> them names, e.g. >> >>Additionaly, a router "A" SHOULD start advertising its own ULA prefix >>whenever the three following conditions are met: >> >>o A stable ULA prefix is advertised by another router "B". >> >>o The router "A" owns the advertised stable ULA prefix. >> >> And then it still doesn't make sense to me (and again I'm asking >> whether we are talking about a /48 or something longer). > > There are only two routers. One is ‘the router’. The other is ‘another > router’. > Is it *that* unclear ? Well, I think I understand, but actually naming the routers avoids all doubt. > >>> A router MUST stop advertising a spontaenously generated ULA prefix >>> whenever one of the two following condition is met: >>> >>> o A different ULA prefix is being advertised. >>> >>> o The same prefix is advertised by another router, and the router >>> doesn't own th
Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
Thank you Brian for your review. See my answers inline. > Hi, > > A few somewhat random comments: > > Everywhere you refer to "small" and "smaller" prefixes. > This is confusing. I assume you mean "long" and "longer ». I guess it’s legitimate. Prefix ‘size’ doesn’t exist, but ‘length’ does. It will get fixed. > >> 4.1. Data structures > ... >> Router ID: The identifier of the advertising router. > > Who assigns this? I think you mention that later but here > it's just a dangling reference. There are multiple references of Router ID before it is defined. I should probably add a terminology section. > >> >> Link ID: If the assignment is made on a connected link, an interface >> identifier of the interface connected to that link. > > That's a bit confusing because a link is not an interface, and the same > link connected to multiple interfaces will have multiple Link IDs > by this definition. Also, you can't call it Interface ID because that > has a specific meaning in IPv6. I don't have a good suggestion but > it needs to be tidied up IMHO. I agree. But as ‘interface ID’ can’t be used, I wonder what could be best. > >> 4.2. Routers' Interfaces >> >> Each interface MUST either be considered as internal or external. >> Prefixes and addresses are only assigned to internal interfaces. The >> criteria to make this distinction are out of the scope of this >> document. > > By "criteria" do you mean mechanisms? That seems to be a discovery > problem (and it also occurs during security bootstrapping). But > I think you really need to define what internal and external *means*. > The words are not self-defining. It is a homenet specific consideration, and is indeed a bootstrapping+configuration problem. I wonder if I shouldn’t separate what is homenet-specific from what is Prefix-Assignment generic. In the prefix assignment context, what ‘internal’ vs ‘external’ means is ‘enabled’ or ‘disabled’ for prefix assignment. Which is why it is not defined in this document. I take good note though and will probably remove that terminology, or rephrase it. Internal Vs External is explained in other documents. > >> If an internal interface becomes external, all prefixes and addresses >> assigned on the considered interface MUST be deleted... > > Yes but... they can't be dropped instantly; at least for v6 they have > to go through the deprecation phase, surely? IMHO, they should be dropped instantly. Because if you start considering a link as external, it means you realized that you have absolutely no right to be a default router on that link. At best, you do something that you shouldn’t do. At worst, the uplink router may kill the port you are connected on. I agree I could clarify though. > > ... >> Whenever two or more interfaces are connected to the same link, > > How is this known to be the case? I imagine a little TV camera > peeping out from the router to look at the cables… In the same paragraph: A mechanism to detect such situation SHOULD be provided by the flooding algorithm. Do you think I should rephrase somehow ? > >> 4.5. Designated Router >> >> On a link where custom host configuration must be provided, or >> whenever SLAAC cannot be used, a DHCP server must be elected. That >> router is called designated router and is dynamically chosen by the >> prefix assignment algorithm. > > You are assuming without stating it that the DHCP server MUST be located > in the same device as a router. Why? In a homenet context, I think it makes sense. Doing it differently would probably increase the algorithm complexity. Now, you’re probably suggesting that, in other scenarios, it may be different ? Do you have a use-case in mind so it would make sense to make it differently ? > > Is the designated router the same one for v4 and v6, and if so, why? Yes. Because the algorithm is agnostic (as much as it can be). > >> 4.5.1. Sending Router Advertisement >> > ... >> The designated router MUST advertise itself as a router for all IPv6 >> delegated prefixes using Route Information Options [RFC4191], >> independently of whether there is a default route or not. > > Why? Maybe different MIF PVDs should be handled by different routers, > if some form of SADR is supported. Because their can only be a single DHCP server on some link, different MIF PVDs will need to be provided by a single router as well. Which is fine. At worse, hosts will send packets to the wrong router, but that router will use Source-Specific-Routing to send it back to the right router (or send a redirect). > >> 6.6. Making a New Assignment > ... >> When the algorithm decides to make a new assignment, it first needs >> to specify the desired size of the assigned prefix. Although this >> algorithm intends to remain generic, the use of 64 bits long prefixes >> is RECOMMENDED (See [I-D.ietf-6man-why64]). > > And for v4? Hard to fulfill that recommandation wi
Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
Thank you Brian for your review. See my answers inline. > Hi, > > A few somewhat random comments: > > Everywhere you refer to "small" and "smaller" prefixes. > This is confusing. I assume you mean "long" and "longer ». I guess it’s legitimate. Prefix ‘size’ doesn’t exist, but ‘length’ does. It will get fixed. > >> 4.1. Data structures > ... >> Router ID: The identifier of the advertising router. > > Who assigns this? I think you mention that later but here > it's just a dangling reference. There are multiple references of Router ID before it is defined. I should probably add a terminology section. > >> >> Link ID: If the assignment is made on a connected link, an interface >> identifier of the interface connected to that link. > > That's a bit confusing because a link is not an interface, and the same > link connected to multiple interfaces will have multiple Link IDs > by this definition. Also, you can't call it Interface ID because that > has a specific meaning in IPv6. I don't have a good suggestion but > it needs to be tidied up IMHO. I agree. But as ‘interface ID’ can’t be used, I wonder what could be best. > >> 4.2. Routers' Interfaces >> >> Each interface MUST either be considered as internal or external. >> Prefixes and addresses are only assigned to internal interfaces. The >> criteria to make this distinction are out of the scope of this >> document. > > By "criteria" do you mean mechanisms? That seems to be a discovery > problem (and it also occurs during security bootstrapping). But > I think you really need to define what internal and external *means*. > The words are not self-defining. It is a homenet specific consideration, and is indeed a bootstrapping+configuration problem. I wonder if I shouldn’t separate what is homenet-specific from what is Prefix-Assignment generic. In the prefix assignment context, what ‘internal’ vs ‘external’ means is ‘enabled’ or ‘disabled’ for prefix assignment. Which is why it is not defined in this document. I take good note though and will probably remove that terminology, or rephrase it. Internal Vs External is explained in other documents. > >> If an internal interface becomes external, all prefixes and addresses >> assigned on the considered interface MUST be deleted... > > Yes but... they can't be dropped instantly; at least for v6 they have > to go through the deprecation phase, surely? IMHO, they should be dropped instantly. Because if you start considering a link as external, it means you realized that you have absolutely no right to be a default router on that link. At best, you do something that you shouldn’t do. At worst, the uplink router may kill the port you are connected on. I agree I could clarify though. > > ... >> Whenever two or more interfaces are connected to the same link, > > How is this known to be the case? I imagine a little TV camera > peeping out from the router to look at the cables… In the same paragraph: A mechanism to detect such situation SHOULD be provided by the flooding algorithm. Do you think I should rephrase somehow ? > >> 4.5. Designated Router >> >> On a link where custom host configuration must be provided, or >> whenever SLAAC cannot be used, a DHCP server must be elected. That >> router is called designated router and is dynamically chosen by the >> prefix assignment algorithm. > > You are assuming without stating it that the DHCP server MUST be located > in the same device as a router. Why? In a homenet context, I think it makes sense. Doing it differently would probably increase the algorithm complexity. Now, you’re probably suggesting that, in other scenarios, it may be different ? Do you have a use-case in mind so it would make sense to make it differently ? > > Is the designated router the same one for v4 and v6, and if so, why? Yes. Because the algorithm is agnostic (as much as it can be). > >> 4.5.1. Sending Router Advertisement >> > ... >> The designated router MUST advertise itself as a router for all IPv6 >> delegated prefixes using Route Information Options [RFC4191], >> independently of whether there is a default route or not. > > Why? Maybe different MIF PVDs should be handled by different routers, > if some form of SADR is supported. Because their can only be a single DHCP server on some link, different MIF PVDs will need to be provided by a single router as well. Which is fine. At worse, hosts will send packets to the wrong router, but that router will use Source-Specific-Routing to send it back to the right router (or send a redirect). > >> 6.6. Making a New Assignment > ... >> When the algorithm decides to make a new assignment, it first needs >> to specify the desired size of the assigned prefix. Although this >> algorithm intends to remain generic, the use of 64 bits long prefixes >> is RECOMMENDED (See [I-D.ietf-6man-why64]). > > And for v4? Hard to fulfill that recommandation wi
Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
Hi, A few somewhat random comments: Everywhere you refer to "small" and "smaller" prefixes. This is confusing. I assume you mean "long" and "longer". > 4.1. Data structures ... >Router ID: The identifier of the advertising router. Who assigns this? I think you mention that later but here it's just a dangling reference. > >Link ID: If the assignment is made on a connected link, an interface > identifier of the interface connected to that link. That's a bit confusing because a link is not an interface, and the same link connected to multiple interfaces will have multiple Link IDs by this definition. Also, you can't call it Interface ID because that has a specific meaning in IPv6. I don't have a good suggestion but it needs to be tidied up IMHO. > 4.2. Routers' Interfaces > >Each interface MUST either be considered as internal or external. >Prefixes and addresses are only assigned to internal interfaces. The >criteria to make this distinction are out of the scope of this >document. By "criteria" do you mean mechanisms? That seems to be a discovery problem (and it also occurs during security bootstrapping). But I think you really need to define what internal and external *means*. The words are not self-defining. >If an internal interface becomes external, all prefixes and addresses >assigned on the considered interface MUST be deleted... Yes but... they can't be dropped instantly; at least for v6 they have to go through the deprecation phase, surely? ... >Whenever two or more interfaces are connected to the same link, How is this known to be the case? I imagine a little TV camera peeping out from the router to look at the cables... > 4.5. Designated Router > >On a link where custom host configuration must be provided, or >whenever SLAAC cannot be used, a DHCP server must be elected. That >router is called designated router and is dynamically chosen by the >prefix assignment algorithm. You are assuming without stating it that the DHCP server MUST be located in the same device as a router. Why? Is the designated router the same one for v4 and v6, and if so, why? > 4.5.1. Sending Router Advertisement > ... >The designated router MUST advertise itself as a router for all IPv6 >delegated prefixes using Route Information Options [RFC4191], >independently of whether there is a default route or not. Why? Maybe different MIF PVDs should be handled by different routers, if some form of SADR is supported. > 6.6. Making a New Assignment ... >When the algorithm decides to make a new assignment, it first needs >to specify the desired size of the assigned prefix. Although this >algorithm intends to remain generic, the use of 64 bits long prefixes >is RECOMMENDED (See [I-D.ietf-6man-why64]). And for v4? > 6.10. Downstream DHCPv6 Prefix Delegation support ... > If DHCPv6 Reconfigure is >not supported, leases lifetimes SHOULD be significantly small. Can't parse "significantly". Can you quantify this? > 9.1.1. Choosing the ULA prefix > >When a stable ULA prefix is advertised, all routers SHOULD remember >that prefix alongwith its associated valid and preferred lifetime. >If this prefix stops being advertised (e.g. due to a network split) >while its preferred lifetime is not null, the same ULA prefix SHOULD >be selected using the same valid and preferred lifetimes. What is doing the selecting? This is a case where the passive tense is confusing. > 9.1.2. Advertising a ULA prefix > >A router MAY start advertising a ULA prefix whenever the two >following conditions are met: > >o It is the network leader. > >o There is no other advertised ULA prefix. > >If no IPv6 prefix is available at all, the network leader SHOULD >start advertising a ULA delegated prefix. Do these two bullets refer to the same thing (a complete ULA /48) or to longer ULA prefixes? > >Additionaly, a router SHOULD start advertising its own ULA prefix >whenever the three following conditions are met: > >o A stable ULA prefix is advertised by another router. > >o The router owns the advertised stable ULA prefix. I got confused about which router is which. Could you give them names, e.g. Additionaly, a router "A" SHOULD start advertising its own ULA prefix whenever the three following conditions are met: o A stable ULA prefix is advertised by another router "B". o The router "A" owns the advertised stable ULA prefix. And then it still doesn't make sense to me (and again I'm asking whether we are talking about a /48 or something longer). >A router MUST stop advertising a spontaenously generated ULA prefix >whenever one of the two following condition is met: > >o A different ULA prefix is being advertised. > >o The same prefix is advertised by another router, and the router > doesn't own
[homenet] I-D Action: draft-ietf-homenet-prefix-assignment-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Prefix and Address Assignment in a Home Network Authors : Pierre Pfister Benjamin Paterson Jari Arkko Filename: draft-ietf-homenet-prefix-assignment-01.txt Pages : 32 Date: 2014-10-24 Abstract: This memo describes a home network prefix and address assignment algorithm running on top of any 'flooding protocol' that fulfills the specified requirements. It is expected that home border routers are allocated one or multiple IPv6 prefixes through DHCPv6 Prefix Delegation (PD) or that prefixes are made available through other means. An IPv4 address can also be assigned and private addresses be used with NAT to provide IPv4 connectivity. In both cases, provided prefixes need to be efficiently divided among the multiple links, and routers need to obtain addresses. This document describes a distributed algorithm for IPv4 and IPv6 prefixes division, assignment and router's address assignment, and specifies how hosts can be given addresses and configuration options using DHCP or SLAAC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-prefix-assignment-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
