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 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 >> >> >> > >> > >> >_______________________________________________ >> >homenet mailing list >> >[email protected] >> >https://www.ietf.org/mailman/listinfo/homenet >> >> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet >> >_______________________________________________ >homenet mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
