In message <cc872d11.1a2ee%d.stu...@att.net> Don Sturek writes: > Hi Robert, > > One more point touched on in your note below: > 1) Ideally, it would be great if a single authorizatative device existed > in the home providing DHCPv6 server services (if supported) and prefix > delegation. > > One challenge in the description below is having multiple routers on > multiple subnets, each possibly acting as a DHCPv6 server within their own > subnet and also providing their own ULA prefix. > > We certainly don't want to further confuse address assignment in a setting > where IT support does not exist. > > Don
We want things to "just work" witb no config. Link local on each subnet and a routing protocol works for any topology. ULA just allows summarization of subnets in the routing protocol, such that host routes are not needed (though not a big deal if host routes are used in a homenet). This would "just work" when using link local or ULA. How to subdivide a GUA prefix among the subnets is another issue. In principle, though I know of no proposals to do this yet, the set of GUA that are available from one of more routers with a provider link could be coordinated via the routing protocol (for example, using a new OSPF Opaque LSA). Curtis > On 9/25/12 1:57 AM, "Robert Cragie" <robert.cra...@gridmerge.com> wrote: > > >So let's tweak Curtis' sequence slightly: > > > >What every host does is: > > > > if it has no MAC: > > pick a random link local address > > else > > use the MAC to create a link local 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; can only use link local address > > > >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 > > > >This should work fine for legacy APs where everything is bridged > >underneath it. Where it gets interesting is in the case of cascaded > >subnets behind a router connected to an ISP, where one or more of those > >subnets may be a mesh network comprised of mesh routers and hosts. I am > >not quite sure how ULAs and DHCPv6 would work in this case as there are > >limitations as far as I can see (although I accept I probably have a bit > >more reading to do on the subject). > > > >Robert > > > >On 25/09/2012 5:45 AM, Curtis Villamizar wrote: > >> In message <cc866762.1a28f%d.stu...@att.net> > >> Don Sturek writes: > >> > >>> 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 > >> > >> Don, > >> > >> You are right about there being nothing to generate the ULA prefix in > >> your example. My mistake. > >> > >> But it doesn't change anything. If the AP is a dumb bridge and there > >> is no router of any kind, then link local addresses are perfectly > >> fine. There is only one subnet in that example, and ULA is not > >> needed. That was the example you gave. > >> > >> Your example had no router just an old AP that acted as a bridge, > >> therefore nothing to generate any sort of RA. If there is a router > >> and no GUA prefix (which is not your example, but a useful example), > >> then ULA can be used. The only RA that is seen is the RA providing a > >> ULA prefix which the router can generate. > >> > >> I did say that the possibility of having to subdivide a /64 only > >> exists for GUA. If a router exists which gets a GUA from a provider, > >> and there are more subnets than the prefix length can support the two > >> options are the ones listed below. (Search for --or--). > >> > >> Curtis > >> > >> > >>> On 9/24/12 6:52 PM, "Curtis Villamizar" <cur...@occnc.com> wrote: > >>> > >>>> In message <cc864fc3.1a27f%d.stu...@att.net> > >>>> 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" <cur...@occnc.com> wrote: > >>>>> > >>>>>> In message <5060bdc7.6020...@freedesktop.org> > >>>>>> 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" <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 > > > _______________________________________________ > 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
