Op 25 sep. 2012, om 21:55 heeft Don Sturek het volgende geschreven: > Hi Teco, > > The main requirement I see is that a home network with multiple ISP > connections, multiple CERs and a shared subnet must support the ability to > discover services within the entire site (home) despite having devices > with differing ULA prefixes and GUA prefixes. > > How would you see discovery working in such a home network?
It might be the right moment to come up with my earlier work on border router discovery. I have to update to incorporate the homenet-arch, and remove details for MANET/Autoconf. Intro & highlights: http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt If there is interest, I'll resubmit for Homenet. Teco > > Don > > > > > On 9/25/12 12:34 PM, "Teco Boot" <[email protected]> wrote: > >> 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 > > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
