IPv4 Proxy-ARP never scaled well and was highly problematic. RFC4903 is informational and merely records some history. It also recommends that link types mcast, ptp, nbma, be used and specifically states "A multi-link subnet model should be avoided."
I don't think MANET and RPL violate the generally accepted definition of subnet. For example, Ethernet bridges do not violate the notion of IP subnet if they run STP or other protocol to learn MAC addresses within the subnet. To IP this is one logical mcast link. MANET is largely experimental (ie: RFC5449, RFC5614, RFC5820, others are experimental). RPL (RFC6550) is more closely analogous to a bridging protocol that operates over a spacific type of subnet. Possibly same with MANET. Both RPL and MANET have requirements that do not apply to the homenet that is running Ethernet and WiFi. If a LOWPAN island running RPL wants to be a single subnet, reachable from the Ethernet and WiFi subnets, that is fine. Some issues may exist if one of the LOWPAN devices is moved out of range or powered off and an RPL island is split into two RPL islands. The use of a single subnet as used in RPL/MANET is specifically discouraged in RFC4903. Curtis In message <[email protected]> Robert Cragie writes: This is a cryptographically signed message in MIME format. --===============5925802905536615095== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040008020704080408030300" This is a cryptographically signed message in MIME format. --------------ms040008020704080408030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Curtis, Comments inline, bracketed by <RCC></RCC> Robert On 01/10/2012 7:11 PM, Curtis Villamizar wrote: > In message <cc8ee0e5.1a5cb%[email protected]> > Don Sturek writes: > =20 >> Hi Curtis, >> =20 >> On the topic of "link local on each subnet and a routing protocol work= s >> for any topology....." >> =20 >> In using 6LoWPAN with ROLL (route over), you end up with a mesh networ= k >> where the scope of link local address is only between a single device = in >> the mesh and its one-hop neighbors (not among all devices in the mesh)= =2E >> =20 >> In a 6LoWPAN/ROLL topology, we need a ULA to allow routable communicat= ions >> between all devices in a single mesh subnet. >> =20 >> Don > > Don, > > The "subnet" is meant in IETF terms, not ITU subnetwork. The subnet > is therefore anything link local by definition. <RCC>Not in the case of RPL or MANETs. This is a multi-link subnet where = routers within the subnet are L3 forwarders (aka "route over").</RCC> > A 6LoWPAN node can > get a GUA and use the GUA (or link local address) of a router as a > default route. If the 6LoWPAN device needs only site connectivity > then it can use the link local address for everything. <RCC>Again, not true in RPL or MANETs. As Don points out, in a RPL/MANET = network, link local means your one-hop neighbors only.</RCC> > > If a routing protocol is in use and is using link local based host > routes, then a router must fake the DAD collision if a duplicate is > found anywhere within the site. If a multiple ULA are used, one per > subnet, then DAD is only relevant to the subnet. A router should pick > a ULA prefix that is not already in use elsewhere in the site. <RCC>In the multi-link subnet, typically a single ULA or GUA would be=20 used for the whole subnet including the routers. Multihoming may be=20 necessary depending on external connectivity.</RCC> > > An extremely low probability race condition exists, but it is a race > condition among routers with multiple routers picking and advertising > the exact same ULA prefix in the routing protocol very nearly > simultaneously (within LAN flooding interval). A wait and backoff can > solve this even though it is a miniscule probability. > > A mesh in IETF terminology is by definition multiple subnets. A > subnet is by definition link local. <RCC>Again, not according to RPL and MANET protocols. There does seem to = have been some discussion on this which probably needs to be resurrected = (see RFC 4903).</RCC> > > Curtis > > >> On 9/30/12 3:36 PM, "Curtis Villamizar" <[email protected]> wrote: >> =20 >>> In message <cc872d11.1a2ee%[email protected]> >>> Don Sturek writes: >>> >>>> Hi Robert, >>>> =20 >>>> 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 pref= ix >>>> delegation. >>>> =20 >>>> One challenge in the description below is having multiple routers on= >>>> multiple subnets, each possibly acting as a DHCPv6 server within the= ir >>>> own >>>> subnet and also providing their own ULA prefix. >>>> =20 >>>> We certainly don't want to further confuse address assignment in a >>>> setting >>>> where IT support does not exist. >>>> =20 >>>> 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 allow= s >>> 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 subdivid= e >>> a GUA prefix among the subnets is another issue. >>> >>> In principle, though I know of no proposals to do this yet, the set o= f >>> 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" <[email protected]> wr= ote: >>>> =20 >>>>> 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 SLA= AC >>>>> 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 t= hose >>>>> 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: >>>>>> =20 >>>>>>> Hi Curtis, >>>>>>> =20 >>>>>>> I think the difficulty is each device cannot "use the MAC to crea= te >>>> 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 th= e >>>> AP >>>>>>> is a >>>>>>> legacy device not capable of providing a ULA prefix, the STA devi= ces >>>>>>> must >>>>>>> use link locals only. >>>>>>> =20 >>>>>>> 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 th= ere >>>>>> 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 route= r >>>>>> 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 providin= g 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 provid= er, >>>>>> 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:= >>>>>>> =20 >>>>>>>> In message <cc864fc3.1a27f%[email protected]> >>>>>>>> Don Sturek writes: >>>>>>>> >>>>>>>>> Hi Curtis, >>>>>>>>> =20 >>>>>>>>> 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 als= o >>>> be >>>>>>>>> supported (and, yes, even for GUA). >>>>>>>>> =20 >>>>>>>>> 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.....) >>>>>>>>> =20 >>>>>>>>> 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 ser= ver >>>>>>>> the address that it already has (from SLAAC). >>>>>>>> >>>>>>>> If as in the case of your Wi-Fi with a bridging AP example, ther= e >>>> is >>>>>>>> no router to give it an DHCPv6 the link local or ULA addresses a= re >>>>>>>> still there and still usable. There is also no router to give i= t >>>> 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 b= een >>>>>>>> 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 use= d) >>>> and >>>>>>>> hand out DHCPv6 addresses and make use of prefixes longer tha= n >>>> /64. >>>>>>>> This prevents the use of CGA but get connectivity to the enti= re >>>>>>>> homenet. >>>>>>>> >>>>>>>> If every consumer oriented provider is willing to allocate prefi= xes >>>>>>>> shorter than /64 on request to home users, then the above situat= ion >>>>>>>> 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]> wrot= e: >>>>>>>>> =20 >>>>>>>>>> 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 hom= e) >>>>>>>>>>>> 3) The only way these new devices can communicate is throug= h >>>>>>>>> address >>>>>>>>>>>> assignment using SLAAC and then some discovery method the tw= o >>>> new >>>>>>>>>>> devices >>>>>>>>>>>> support (without support from the AP). Here these devices a= re >>>>>>>>>>> assuming >>>>>>>>>>>> bridging through the AP...... >>>>>>>>>>> =20 >>>>>>>>>>> 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 t= he >>>>>>>>>> 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 IPv= 6 >>>>>>>>> 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. >>>>>>>>>>> =20 >>>>>>>>>>> Good point. >>>>>>>>>> But invalid. The use case Don gave would still work fine. On= ly >>>> GUA >>>>>>>>>> addresses are affected. >>>>>>>>>> >>>>>>>>>>> I loathe DHCP (of any sort) *for basic address assignment, >>>> anyway* >>>>>>>>>>> in >>>>>>>>>>> the home environment. >>>>>>>>>>> =20 >>>>>>>>>>> The loathing comes from the exquisite pain of suffering with = a >>>>>>>>>>> flaky >>>>>>>>>>> home network for several months, before realising I had a ro= gue >>>>>>>>>>> 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 you= r >>>>>>>>>> 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 ho= me >>>>>>>>> network >>>>>>>>>>> in normal operation. >>>>>>>>>>> =20 >>>>>>>>>>> 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 cal= l >>>>>>>>>> lasted >>>>>>>>>> longer than the DHCPv4 lease, then it lost the least because i= t >>>>>>>>>> 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 nothin= g >>>> 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, >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> SLAAC not working is a major problem. >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>> Don >>>>>>>>>>>>> Don, >>>>>>>>>>>>> >>>>>>>>>>>>> Why? This is an assertion without basis as far as I am >>>>>>>>>>>>> concerned. >>>>>>>>>>>>> Except CGA there is nothing that breaks without SLAAC. Joe= l >>>>>>>>> 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 a= nd >>>>>>>>> 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 h= ost >>>>>>>>> ever >>>>>>>>>>>>> tries to generate an address using SLAAC. The only >>>> constraint is >>>>>>>>>>> that >>>>>>>>>>>>> any host connecting to my Ethernet or wireless must run a D= HCP >>>>>>>>> client >>>>>>>>>>>>> and if they want an IPv6 GUA must run a DHCPv6 client. DHC= Pv4 >>>>>>>>>>>>> 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: >>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>> In message <[email protected]> >>>>>>>>>>>>>>> "Joel M. Halpern" writes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since you invited flames... >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> 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 rece= ntly >>>>>>>>>>> relaxed. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>> =20 >>>>>>>>>>>>>>>> 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 ne= ver >>>>>>>>> been a >>>>>>>>>>>>>>> fan of security half measures. Yes anti-spoofing without= >>>> prior >>>>>>>>>>>>>>> exchange of a key is nice, but no reasonable authorizatio= n >>>>>>>>> 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 w= ill >>>>>>>>> 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 o= ut >>>> 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 n= eed >>>>>>>>> subnets. >>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>> does work and it is no more unnatural than >>>>>>>>>>>>>>>>> subnetting a >>>>>>>>>>>>>> class-A >>>>>>>>>>>>>>>>> network would be in 1990. It means using DHCP= v6 >>>> 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 > --------------ms040008020704080408030300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjEwMDIxNTUwMjJaMCMGCSqGSIb3DQEJBDEWBBTXDhjAjOqRdK7K6rFevOFoasW/OzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJgidojEfjQIWnjPN+qBbiOv+Hvo4sA4jFpfObhu5rG7MIRx bUksm/add2wGx8OfURZMtLc4KDvmHUXNLSsdTNHPcQinCBtgvA94Ysx0dGE/ZLyhra+UAR5u gAvikXZka3P5YNqyh3S1Xus3GeMoxQYcuczlD++HR1+0ADVSRGkNx5GigLoEiJXbkneT3cab CgcoqsllEL2dmP49ZzHExQh4Ipadfd1+jvu78sBuHyOHsvKyuFkSiWb998b8W9wBTFQO8vfC l1yfia07abQLcY2723wT/7h6boHkXs5Cupar3j+O7p9QDs8zgIxR9FlI8C1jikwnsVLrecnS wcjderAAAAAAAAA= --------------ms040008020704080408030300-- --===============5925802905536615095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet --===============5925802905536615095==-- _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
