On 25/09/2012 02:01, Don Sturek wrote: > 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).
It MUST be supported according to RFC 6204 and 6204bis (and of course by all hosts, according to RFC 6434). Brian > > 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 > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
