In message <0abfee76-7737-41b7-96e1-8d90a0eff...@inf-net.nl> Teco Boot writes: > > 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
Just looked at that draft. It solves one of the problems, having more than one GUA prefix. It does not solve another closely related problem, having more than one subnet behind the CER or border routers (BR101 and BR201 in your diagram) where there is no prior configuration. In your "Figure 2: Scenario 2" all routers have the same set of addresses on each of their interfaces. This is not generally how subnets are laid out. Each interface on a router gets a different link local address. The /48 is usually split into a set of /64, one per subnet. In a managed network (enterprise, clueful soho, etc) the split of a /48 into 16 or less /64s today is done by configuration (configuration of prefixes on the routers or DHCP server and relays). Curtis > > Don > > > > > > > > > > On 9/25/12 12:34 PM, "Teco Boot" <t...@inf-net.nl> 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" <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
