In message <cc85fd9e.1a22f%d.stu...@att.net> Don Sturek writes: > 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......
Fine. Use link local addresses. SLAAC simply can't be used with the GUA prefix. SLAAC can be used with link local or ULA. Does this mean problem solved? > 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. > > Don Maybe I wasn't clear in the summary paragraph. SLAAC can still be used but not for GUA. For the GUA DHCPv6 can be used and SLACC has to be avoided *if* the provider forced subdividing a /64 by refusing to allocate a prefix large enough (for example a fixed policy of /64 only for homes). I am not suggesting depricating SLAAC or not implementing it. All I am suggesting is that *if* you have a prefix that is too small, then you can sacrifice CGA but still support all the subnets you need by not providing an RA and providing DHCPv6 for the GUA prefixes that need to be longer than /64 within the homenet. If providers are all cooperative and are all willing to give out short enough prefixes, then the "if" in the prior paragraph never evaluates to "true" and the suggestion is a NOOP. I hope that was a bit more clear. btw- It seems to me that some respondents are reading the diffs to the draft and are replying only to the summary (or worse yet replying only to Joel's comment on summary point #12). Any reply is better than none, but please also read the diffs to the draft. Curtis > On 9/24/12 11:49 AM, "Curtis Villamizar" <cur...@occnc.com> wrote: > > > > >In message <cc84f8f1.1a1c4%d.stu...@att.net> > >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" <cur...@occnc.com> wrote: > >> > >> > > >> >In message <505e83f6.3030...@joelhalpern.com> > >> >"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 > >> >homenet@ietf.org > >> >https://www.ietf.org/mailman/listinfo/homenet > > > >_______________________________________________ > >homenet mailing list > >homenet@ietf.org > >https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
