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