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 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
