Op 25 sep. 2012, om 18:47 heeft Don Sturek het volgende geschreven: Sorry to jump in.
> 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. I don't agree. When adding another gateway, to another ISP, I would like such to be independent form the existing gear. (3.2.2.2. B: Two ISPs, Two CERs, Shared subnet) > 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. When hosts get their addresses for each RA prefix, by using SLAAC and/or DHCPv6, what is the challenge? (protocol-wise, not current host behavior) When hosts get only one GUA, they will use only one link to one ISP (no translation). For multi-path, this needs an update. > > We certainly don't want to further confuse address assignment in a setting > where IT support does not exist. Agreed, we need to improve address assignment. And routing based on destination & source addresses. Teco > > Don > > > > > On 9/25/12 1:57 AM, "Robert Cragie" <[email protected]> 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%[email protected]> >>> 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" <[email protected]> wrote: >>>> >>>>> In message <cc864fc3.1a27f%[email protected]> >>>>> 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" <[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 > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
