In message <cc8ee0e5.1a5cb%[email protected]> Don Sturek writes: > Hi Curtis, > > On the topic of "link local on each subnet and a routing protocol works > for any topology....." > > In using 6LoWPAN with ROLL (route over), you end up with a mesh network > where the scope of link local address is only between a single device in > the mesh and its one-hop neighbors (not among all devices in the mesh). > > In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communications > between all devices in a single mesh subnet. > > Don
Don, The "subnet" is meant in IETF terms, not ITU subnetwork. The subnet is therefore anything link local by definition. A 6LoWPAN node can get a GUA and use the GUA (or link local address) of a router as a default route. If the 6LoWPAN device needs only site connectivity then it can use the link local address for everything. If a routing protocol is in use and is using link local based host routes, then a router must fake the DAD collision if a duplicate is found anywhere within the site. If a multiple ULA are used, one per subnet, then DAD is only relevant to the subnet. A router should pick a ULA prefix that is not already in use elsewhere in the site. An extremely low probability race condition exists, but it is a race condition among routers with multiple routers picking and advertising the exact same ULA prefix in the routing protocol very nearly simultaneously (within LAN flooding interval). A wait and backoff can solve this even though it is a miniscule probability. A mesh in IETF terminology is by definition multiple subnets. A subnet is by definition link local. Curtis > On 9/30/12 3:36 PM, "Curtis Villamizar" <[email protected]> wrote: > > > > >In message <cc872d11.1a2ee%[email protected]> > >Don Sturek writes: > > > >> Hi Robert, > >> > >> One more point touched on in your note below: > >> 1) Ideally, it would be great if a single authorizatative device > >>existed > >> in the home providing DHCPv6 server services (if supported) and prefix > >> delegation. > >> > >> One challenge in the description below is having multiple routers on > >> multiple subnets, each possibly acting as a DHCPv6 server within their > >>own > >> subnet and also providing their own ULA prefix. > >> > >> We certainly don't want to further confuse address assignment in a > >>setting > >> where IT support does not exist. > >> > >> Don > > > > > >We want things to "just work" witb no config. Link local on each > >subnet and a routing protocol works for any topology. ULA just allows > >summarization of subnets in the routing protocol, such that host > >routes are not needed (though not a big deal if host routes are used > >in a homenet). > > > >This would "just work" when using link local or ULA. How to subdivide > >a GUA prefix among the subnets is another issue. > > > >In principle, though I know of no proposals to do this yet, the set of > >GUA that are available from one of more routers with a provider link > >could be coordinated via the routing protocol (for example, using a > >new OSPF Opaque LSA). > > > >Curtis > > > > > >> On 9/25/12 1:57 AM, "Robert Cragie" <[email protected]> wrote: > >> > >> >So let's tweak Curtis' sequence slightly: > >> > > >> >What every host does is: > >> > > >> > if it has no MAC: > >> > pick a random link local address > >> > else > >> > use the MAC to create a link local address > >> > run DAD to make sure no one else has same address > >> > > >> > send a RS > >> > > >> > if it gets RA > >> > use the RA prefix for SLAAC > >> > else > >> > time out and don't bother with SLAAC; can only use link local > >>address > >> > > >> >then hopefully the host also does the following: > >> > > >> > send DHCPv6 client request > >> > > >> > if response > >> > it has yet another address to pick from if it got one using SLAAC > >> > else > >> > time out and get nothing from DHCPv6 > >> > > >> >This should work fine for legacy APs where everything is bridged > >> >underneath it. Where it gets interesting is in the case of cascaded > >> >subnets behind a router connected to an ISP, where one or more of those > >> >subnets may be a mesh network comprised of mesh routers and hosts. I am > >> >not quite sure how ULAs and DHCPv6 would work in this case as there are > >> >limitations as far as I can see (although I accept I probably have a > >>bit > >> >more reading to do on the subject). > >> > > >> >Robert > >> > > >> >On 25/09/2012 5:45 AM, Curtis Villamizar wrote: > >> >> In message <cc866762.1a28f%[email protected]> > >> >> Don Sturek writes: > >> >> > >> >>> Hi Curtis, > >> >>> > >> >>> I think the difficulty is each device cannot "use the MAC to create > >>a > >> >>>ULA > >> >>> address". Some authoritative device in the network (eg, the AP) > >>must > >> >>> create the ULA prefix. If a ULA prefix is not present because the > >>AP > >> >>>is a > >> >>> legacy device not capable of providing a ULA prefix, the STA devices > >> >>>must > >> >>> use link locals only. > >> >>> > >> >>> Don > >> >> > >> >> Don, > >> >> > >> >> You are right about there being nothing to generate the ULA prefix in > >> >> your example. My mistake. > >> >> > >> >> But it doesn't change anything. If the AP is a dumb bridge and there > >> >> is no router of any kind, then link local addresses are perfectly > >> >> fine. There is only one subnet in that example, and ULA is not > >> >> needed. That was the example you gave. > >> >> > >> >> Your example had no router just an old AP that acted as a bridge, > >> >> therefore nothing to generate any sort of RA. If there is a router > >> >> and no GUA prefix (which is not your example, but a useful example), > >> >> then ULA can be used. The only RA that is seen is the RA providing a > >> >> ULA prefix which the router can generate. > >> >> > >> >> I did say that the possibility of having to subdivide a /64 only > >> >> exists for GUA. If a router exists which gets a GUA from a provider, > >> >> and there are more subnets than the prefix length can support the two > >> >> options are the ones listed below. (Search for --or--). > >> >> > >> >> Curtis > >> >> > >> >> > >> >>> On 9/24/12 6:52 PM, "Curtis Villamizar" <[email protected]> wrote: > >> >>> > >> >>>> In message <cc864fc3.1a27f%[email protected]> > >> >>>> Don Sturek writes: > >> >>>> > >> >>>>> Hi Curtis, > >> >>>>> > >> >>>>> I would expect most Wi-Fi AP manufacturers to support the same > >> >>>>>address > >> >>>>> assignment they do today (ie, manual assignment and DHCP). I > >>would > >> >>>>> also expect as more IPv6 deployments happen that SLAAC will also > >>be > >> >>>>> supported (and, yes, even for GUA). > >> >>>>> > >> >>>>> For the types of devices which will be added to Wi-Fi networks in > >>the > >> >>>>> future (eg, headless devices like appliances, thermostats, etc.) > >>that > >> >>>>> the preferred address assignment will be SLAAC and DHCPv6 (and, > >>yes, > >> >>>>>I > >> >>>>> purposely did not remove SLAAC.....) > >> >>>>> > >> >>>>> Don > >> >>>> > >> >>>> Don, > >> >>>> > >> >>>> We seem to be talking past each other so let me again try to be > >>clear. > >> >>>> > >> >>>> What every host does is: > >> >>>> > >> >>>> if it has no MAC: > >> >>>> pick a random link local (not ULA) address > >> >>>> else > >> >>>> use the MAC to create a ULA address > >> >>>> run DAD to make sure no one else has same address > >> >>>> > >> >>>> send a RS > >> >>>> > >> >>>> if it gets RA > >> >>>> use the RA prefix for SLAAC > >> >>>> else > >> >>>> time out and don't bother with SLAAC > >> >>>> > >> >>>> then hopefully the host also does the following: > >> >>>> > >> >>>> send DHCPv6 client request > >> >>>> > >> >>>> if response > >> >>>> it has yet another address to pick from if it got one using > >>SLAAC > >> >>>> else > >> >>>> time out and get nothing from DHCPv6 > >> >>>> > >> >>>> Note: new extensions to DHCPv6 allow the host to tell DHCPv6 server > >> >>>> the address that it already has (from SLAAC). > >> >>>> > >> >>>> If as in the case of your Wi-Fi with a bridging AP example, there > >>is > >> >>>> no router to give it an DHCPv6 the link local or ULA addresses are > >> >>>> still there and still usable. There is also no router to give it > >>an > >> >>>> RA response so it has no SLAAC assigned address and no DHCPv6 > >>assigned > >> >>>> address. > >> >>>> > >> >>>> That is the end of your example. > >> >>>> > >> >>>> If there is a router then there is something that can hand out a > >>RA or > >> >>>> DHCPv6 response. > >> >>>> > >> >>>> In the case were there exists multiple subnets and the CER has been > >> >>>> granted a /64 (or too few /64s to handle the number of subnets), > >>then: > >> >>>> > >> >>>> it can use RA with /64 on some subnets and give them GUA > >>addresses > >> >>>> and some subnets have no access outside the homenet > >> >>>> > >> >>>> --or-- > >> >>>> > >> >>>> it can not use RA (and therefore prevent SLAAC from being used) > >>and > >> >>>> hand out DHCPv6 addresses and make use of prefixes longer than > >>/64. > >> >>>> This prevents the use of CGA but get connectivity to the entire > >> >>>> homenet. > >> >>>> > >> >>>> If every consumer oriented provider is willing to allocate prefixes > >> >>>> shorter than /64 on request to home users, then the above situation > >> >>>> never occurs. If it does, my argument is that the second option > >>above > >> >>>> is better than the first. > >> >>>> > >> >>>> Curtis > >> >>>> > >> >>>> > >> >>>>> On 9/24/12 5:11 PM, "Curtis Villamizar" <[email protected]> wrote: > >> >>>>> > >> >>>>>> In message <[email protected]> > >> >>>>>> Jim Gettys writes: > >> >>>>>> > >> >>>>>>> On 09/24/2012 03:17 PM, Don Sturek wrote: > >> >>>>>>>> Hi Curtis, > >> >>>>>>>> > >> >>>>>>>> Here is the use case: > >> >>>>>>>> 1) Customer has a legacy AP in their house > >> >>>>>>>> 2) Customer brings home new devices supporting IPv6 (which are > >> >>>>>>> designed > >> >>>>>>>> to communicate only with other IPv6 based devices in the home) > >> >>>>>>>> 3) The only way these new devices can communicate is through > >> >>>>> address > >> >>>>>>>> assignment using SLAAC and then some discovery method the two > >>new > >> >>>>>>> devices > >> >>>>>>>> support (without support from the AP). Here these devices are > >> >>>>>>> assuming > >> >>>>>>>> bridging through the AP...... > >> >>>>>>> > >> >>>>>>> And since current legacy AP's all bridge, we win (even though we > >> >>>>> need to > >> >>>>>>> route in the future). > >> >>>>>> Jim, > >> >>>>>> > >> >>>>>> The point was how do you get local IPv6 within the home with the > >> >>>>>> legacy AP that does only IPv4 and just does bridging of IPv6. > >>First > >> >>>>>> of all you have no subnets. There is no CER to do DHCPv6. > >> >>>>>> > >> >>>>>> In this case you use link local or if everything has a MAC you > >>can > >> >>>>>>use > >> >>>>>> ULA based on the MAC addressses. > >> >>>>>> > >> >>>>>>>> Placing a requirement that every customer who buys a new IPv6 > >> >>>>> device, > >> >>>>>>>> intended to communicate only with other IPv6 devices in the > >>home, > >> >>>>> will > >> >>>>>>>> require a forklift upgrade of a deployed network in order to > >>work > >> >>>>>>> will not > >> >>>>>>>> be popular. > >> >>>>>>> > >> >>>>>>> Good point. > >> >>>>>> But invalid. The use case Don gave would still work fine. Only > >>GUA > >> >>>>>> addresses are affected. > >> >>>>>> > >> >>>>>>> I loathe DHCP (of any sort) *for basic address assignment, > >>anyway* > >> >>>>>>>in > >> >>>>>>> the home environment. > >> >>>>>>> > >> >>>>>>> The loathing comes from the exquisite pain of suffering with a > >> >>>>>>>flaky > >> >>>>>>> home network for several months, before realising I had a rogue > >> >>>>>>>DHCP > >> >>>>>>> server somewhere on my network (from wireshark). I then had to > >> >>>>>>>take > >> >>>>> the > >> >>>>>>> mac address, figure out who may have manufactured some device > >>from > >> >>>>> that > >> >>>>>>> information, and finally figured out the little VOIP ATA > >>adaptor I > >> >>>>> had > >> >>>>>>> been given liked to do DHCP. > >> >>>>>> It did DHCP on the *WAN side*? You didn't put the rest of your > >> >>>>>> network behind the VOIP box on the LAN side I hope. > >> >>>>>> > >> >>>>>>> This was by far the hardest debugging I've had to do in my home > >> >>>>> network > >> >>>>>>> in normal operation. > >> >>>>>>> > >> >>>>>>> This is well beyond normal home debugging capability of > >>consumers. > >> >>>>>>> - Jim > >> >>>>>> We all have plenty of crappy IPv4 product horror stories. My > >>VOIP > >> >>>>>> phone locked up now and then and I figured out that if the call > >> >>>>>>lasted > >> >>>>>> longer than the DHCPv4 lease, then it lost the least because it > >> >>>>>>didn't > >> >>>>>> try to renew it. Not only did the call drop, but the device > >>locked > >> >>>>>> up. The first solution was to reboot it now and then. The > >>answer > >> >>>>>>was > >> >>>>>> to configure a fixed address. I was lucky to figure it out > >>before > >> >>>>>>my > >> >>>>>> wife threw the phone through a window. For all I know a later > >> >>>>>> firmware upgrade might have fixed it. VOIP might be more > >>popular if > >> >>>>>> VOIP phones under $600 worked reasonably well. > >> >>>>>> > >> >>>>>> Both nice stories, but both are DHCPv4 related and have nothing > >>at > >> >>>>>>all > >> >>>>>> to do with SLAAC. > >> >>>>>> > >> >>>>>> Curtis > >> >>>>>> > >> >>>>>>>> Don > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On 9/24/12 11:49 AM, "Curtis Villamizar" <[email protected]> > >>wrote: > >> >>>>>>>> > >> >>>>>>>>> In message <cc84f8f1.1a1c4%[email protected]> > >> >>>>>>>>> Don Sturek writes: > >> >>>>>>>>> > >> >>>>>>>>>> Hi Curtis, > >> >>>>>>>>>> > >> >>>>>>>>>> SLAAC not working is a major problem. > >> >>>>>>>>>> > >> >>>>>>>>>> Don > >> >>>>>>>>> Don, > >> >>>>>>>>> > >> >>>>>>>>> Why? This is an assertion without basis as far as I am > >> >>>>>>>>>concerned. > >> >>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joel > >> >>>>> brought > >> >>>>>>>>> up ILNP in private email, but I beleive ILNP can also work as > >>the > >> >>>>>>>>> constraints in ILNP are in the ILNP identifier which is not > >>the > >> >>>>> same > >> >>>>>>>>> as the interface address in ILNP for which there is no > >> >>>>>>>>>constraint. > >> >>>>>>>>> > >> >>>>>>>>> I have subnets running fine using a few /112 allocated from > >> >>>>> within a > >> >>>>>>>>> /64 with fixed addresses on rack mount hosts and desktops and > >> >>>>> DHCPv6 > >> >>>>>>>>> for dynamic allocations for laptops. It works fine. Link > >>local > >> >>>>>>>>> addresses are all that is needed to get DHCPv6 to work. No > >>host > >> >>>>> ever > >> >>>>>>>>> receives a RA since my routers won't give them one, so no host > >> >>>>> ever > >> >>>>>>>>> tries to generate an address using SLAAC. The only > >>constraint is > >> >>>>>>> that > >> >>>>>>>>> any host connecting to my Ethernet or wireless must run a DHCP > >> >>>>> client > >> >>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 > >> >>>>>>>>>and > >> >>>>>>>>> DHCPv6 servers are available in every subnet except one GbE > >> >>>>> subnet in > >> >>>>>>>>> the rack and to a few hosts in my home office. > >> >>>>>>>>> > >> >>>>>>>>> So as far as I am concerned we have an assertion that no > >>SLAAC is > >> >>>>> a > >> >>>>>>>>> problem and existance proof that it is not. Beside CGA and > >> >>>>> requiring > >> >>>>>>>>> that hosts run DHCPv6 if they want an IPv6 GUA, what can I not > >> >>>>>>> support > >> >>>>>>>>> on these /112 subnets? > >> >>>>>>>>> > >> >>>>>>>>> Curtis > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>>> On 9/23/12 4:09 PM, "Curtis Villamizar" <[email protected]> > >> >>>>>>>>>>wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> In message <[email protected]> > >> >>>>>>>>>>> "Joel M. Halpern" writes: > >> >>>>>>>>>>> > >> >>>>>>>>>>>> Since you invited flames... > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The argument on /64 as the longest prefix is not that it is > >> >>>>>>> magically > >> >>>>>>>>>>>> unnatural. > >> >>>>>>>>>>>> Rather, it is that there are a number of current and > >>evolving > >> >>>>>>>>>> protocols > >> >>>>>>>>>>>> that depend upon that /64. The obvious example is that > >>SLAAC > >> >>>>> does > >> >>>>>>>>>> not > >> >>>>>>>>>>>> work if subnets are longer than /64. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The rules in this regard are written into approved RFCs. > >>If > >> >>>>>>> homenet > >> >>>>>>>>>>>> wants to change that, it really needs to go to 6man with a > >> >>>>> strong > >> >>>>>>>>>> case. > >> >>>>>>>>>>>> (for point-to-point inter-router links this was recently > >> >>>>>>> relaxed. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> At the same time, andy operator who insists on giving > >>homes a > >> >>>>> /64 > >> >>>>>>> is > >> >>>>>>>>>>>> being inappropriately restrictive. Homenet should say > >>that, > >> >>>>>>> rather > >> >>>>>>>>>>>> than > >> >>>>>>>>>>>> trying to change the IPv6 architecture. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Yours, > >> >>>>>>>>>>>> Joel > >> >>>>>>>>>>> Joel, > >> >>>>>>>>>>> > >> >>>>>>>>>>> I don't consider your email a flame at all. Thanks for > >> >>>>> responding. > >> >>>>>>>>>>> SLAAC (which I am not at a fan of) won't work but DHCPv6 > >>will > >> >>>>>>>>>>>so > >> >>>>>>> IMHO > >> >>>>>>>>>>> no loss. CGA also won't work but then again I've also never > >> >>>>> been a > >> >>>>>>>>>>> fan of security half measures. Yes anti-spoofing without > >>prior > >> >>>>>>>>>>> exchange of a key is nice, but no reasonable authorization > >> >>>>> could be > >> >>>>>>>>>>> based on CGA without also exchanging some sort of key or > >>cert > >> >>>>> and > >> >>>>>>> at > >> >>>>>>>>>>> that point the CGA as a public key is redundant. > >> >>>>>>>>>>> > >> >>>>>>>>>>> If SLAAC and CGA are the only things that break *and* > >>providers > >> >>>>> do > >> >>>>>>>>>>> hand out prefixes that are too small, then /64 prefixes will > >> >>>>> have > >> >>>>>>> to > >> >>>>>>>>>>> be subdivided. > >> >>>>>>>>>>> > >> >>>>>>>>>>> So a question for you is what else if anything will break? > >> >>>>>>>>>>> > >> >>>>>>>>>>> I also understand that you are suggesting that this be > >>taken to > >> >>>>>>> 6man. > >> >>>>>>>>>>> That is a good suggestion. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Curtis > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>>>> On 9/22/2012 11:30 PM, Curtis Villamizar wrote: > >> >>>>>>>>>>>>> 12. This is sure to be controversial. I pointed out > >>that > >> >>>>>>> using > >> >>>>>>>>>>>>> subnets longer than /64 is OK as long as they are > >>not > >> >>>>>>> leaked > >> >>>>>>>>>>>>> into global routing. Please read the text and > >> >>>>>>>>>>>>>changes > >> >>>>>>>>>> before > >> >>>>>>>>>>>>> exploding on this topic. It may be necessary to > >> >>>>> subnet a > >> >>>>>>>>>> /64 > >> >>>>>>>>>>>> if > >> >>>>>>>>>>>>> that is all a provider will give you and you need > >> >>>>> subnets. > >> >>>>>>>>>> It > >> >>>>>>>>>>>>> does work and it is no more unnatural than > >> >>>>>>>>>>>>>subnetting a > >> >>>>>>>>>> class-A > >> >>>>>>>>>>>>> network would be in 1990. It means using DHCPv6 > >>and > >> >>>>> not > >> >>>>>>>>>> using > >> >>>>>>>>>>>>> RA prefixes for GUA (otherwise SLAAC > >>implementations > >> >>>>> would > >> >>>>>>>>>>>>> likely try to use the whole bottom 64). > >> >>>>>> _______________________________________________ > >> >>>>>> homenet mailing list > >> >>>>>> [email protected] > >> >>>>>> https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
