In message <[email protected]> Brian E Carpenter writes: > 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
Brian, The "I would expect" wording is due to the very long lag between RFC mandates and the consumer products on retailer shelves that support those RFCs. Consumer products have yet to catch up to the RFCs in the 2xxx and 3xxx RFC range let alone anything in the 6xxx range. For example, the 4 port GbE and 2 Wifi channel AP I recently bought to run cerowrt supported little more than bridging IPv6 with the vendor firmware yet is advertised as having IPv6 support. That is not even the low end of consumer products. Curtis > > 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
