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 DHCPv6This 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 ULAaddress". 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.DonDon, 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--). CurtisOn 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 addressassignment 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 thefuture (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.....)DonDon, 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. CurtisOn 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 aredesignedto communicate only with other IPv6 based devices in the home) 3) The only way these new devices can communicate is throughaddressassignment using SLAAC and then some discovery method the two newdevicessupport (without support from the AP). Here these devices areassumingAnd since current legacy AP's all bridge, we win (even though webridging through the AP......need toroute 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 IPv6device,intended to communicate only with other IPv6 devices in the home,willrequire a forklift upgrade of a deployed network in order to workwill notGood point.be popular.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 flakyhome network for several months, before realising I had a rogue DHCP server somewhere on my network (from wireshark). I then had to takethemac address, figure out who may have manufactured some device fromthatinformation, and finally figured out the little VOIP ATA adaptor Ihadbeen 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 homenetworkin normal operation.This is well beyond normal home debugging capability of consumers.- JimWe 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. CurtisDon 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. DonDon, Why? This is an assertion without basis as far as I am concerned. Except CGA there is nothing that breaks without SLAAC. Joelbroughtup ILNP in private email, but I beleive ILNP can also work as the constraints in ILNP are in the ILNP identifier which is not thesameas the interface address in ILNP for which there is no constraint. I have subnets running fine using a few /112 allocated fromwithin a/64 with fixed addresses on rack mount hosts and desktops andDHCPv6for dynamic allocations for laptops. It works fine. Link local addresses are all that is needed to get DHCPv6 to work. No hosteverreceives a RA since my routers won't give them one, so no hostevertries to generate an address using SLAAC. The only constraint isthatany host connecting to my Ethernet or wireless must run a DHCPclientand if they want an IPv6 GUA must run a DHCPv6 client. DHCPv4 and DHCPv6 servers are available in every subnet except one GbEsubnet inthe rack and to a few hosts in my home office. So as far as I am concerned we have an assertion that no SLAAC isaproblem and existance proof that it is not. Beside CGA andrequiringthat hosts run DHCPv6 if they want an IPv6 GUA, what can I notsupporton these /112 subnets? CurtisOn 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 ismagicallyunnatural. Rather, it is that there are a number of current and evolvingprotocolsthat depend upon that /64. The obvious example is that SLAACdoesnotwork if subnets are longer than /64.The rules in this regard are written into approved RFCs. Ifhomenetwants to change that, it really needs to go to 6man with astrongcase.(for point-to-point inter-router links this was recentlyrelaxed.At the same time, andy operator who insists on giving homes a/64isbeing inappropriately restrictive. Homenet should say that,ratherthan trying to change the IPv6 architecture.Yours,JoelJoel, I don't consider your email a flame at all. Thanks forresponding.SLAAC (which I am not at a fan of) won't work but DHCPv6 will soIMHOno loss. CGA also won't work but then again I've also neverbeen afan of security half measures. Yes anti-spoofing without prior exchange of a key is nice, but no reasonable authorizationcould bebased on CGA without also exchanging some sort of key or certandatthat point the CGA as a public key is redundant. If SLAAC and CGA are the only things that break *and* providersdohand out prefixes that are too small, then /64 prefixes willhavetobe subdivided. So a question for you is what else if anything will break? I also understand that you are suggesting that this be taken to6man.That is a good suggestion. CurtisOn 9/22/2012 11:30 PM, Curtis Villamizar wrote:12. This is sure to be controversial. I pointed out thatusingsubnets longer than /64 is OK as long as they are notleakedinto global routing. Please read the text and changesbeforeexploding on this topic. It may be necessary tosubnet a/64ifthat is all a provider will give you and you needsubnets.Itdoes work and it is no more unnatural than subnetting aclass-Anetwork would be in 1990. It means using DHCPv6 andnotusingRA prefixes for GUA (otherwise SLAAC implementationswouldlikely 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
