Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Fernando Gont <fgont@si6networks.com> Sun, 03 February 2019 16:01 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3212008F; Sun, 3 Feb 2019 08:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pJF0emmBlrK; Sun, 3 Feb 2019 08:01:36 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EEC128CB7; Sun, 3 Feb 2019 08:01:35 -0800 (PST)
Received: from [192.168.3.66] (unknown [186.137.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 31CBB84236; Sun, 3 Feb 2019 17:01:28 +0100 (CET)
To: Ole Troan <otroan@employees.org>
Cc: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com>
Date: Sun, 03 Feb 2019 13:01:14 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xRfdRyg-9F1iHy_naZhNUkv-4pM>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Feb 2019 16:01:41 -0000
On 3/2/19 12:26, Ole Troan wrote: >>>> >>>> Well, the problem is that you are making a contract on the LAN side for >>>> a contract you may not have on the WAN side. If the router reboots and >>>> the CEP no longer "owns" some prefix, then that contract is void. >>> >>> You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020. >>> A reboot doesn’t change that. >>> >>>> Ideally, the CPE will advertise that the contract is void. But it is >>>> clear that for most deployed CPEs, that will not happen. >>> >>> So a bug. >>> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. >> >> The CPE is the middle-man between the ISP and the LAN. No matter what >> you may *expect* the CPE to do, the CPE is currently not actually >> required to e.g. clean after the contract that the ISP broke (if you >> assume/think there's such a thing), or even adjust prefix timers >> according to the DHCPv6 lease times -- talk about under-specification of >> the glue between e.g. DHCPv6-PD and SLAAC. > > RFC3633: > Each prefix has an associated valid and preferred lifetime, which > constitutes an agreement about the length of time over which the > requesting router is allowed to use the prefix. A requesting router > can request an extension of the lifetimes on a delegated prefix and > is required to terminate the use of a delegated prefix if the valid > lifetime of the prefix expires. > > This really isn’t hard. It's not hard. But it just doesn't happen in crash-and-reboot scenarios for most CPEs nowadays. >> Besides, the layer-8 contract between the user and the ISP may be that >> you get dynamic prefixes. This means that whenever you request a lease, >> you get a different prefix. You might say that if you don't do another >> DHCPv6-PD request, you should be able to use the same prefix. But if you >> do ask a new prefix, you might indeed get a new one -- and this is what >> normally happens after reboots. > > Not normally. That’s ISP allocation policy. > And not recommended. The RIPE document does not recommend it. In Germany, that's the expected default. At the end of the day, it's a policy. > But sure a correctly behaving DHCP PD implementation will include the current prefixes in it’s request message. But they may just not know what they were (unless the previously-leased prefix was recorded on stable storage). Or the DHCPv6 server might lease something else. >>>>> What you seem to be talking about is either a bug a misconfiguration or both. >>>> >>>> It's neither of those. If anything, it's the result of >>>> under-specification of the necessary glue between automatic >>>> configuration on the WAN side, and automatic configuration on the LAN side. >>>> >>>> e.g., there were no requirements for CPEs to keep track of prefixes that >>>> they have been leased in the past -- if at all possible. >>> >>> DHCP PD will give you the old prefix back. >> >> Not necessarily. In fact, it may intentionally not do that. If you no >> longer own the addresses, the sessions will have to be torn down. > > That’s not how IPv6 addressing and renumbering is intended to work. > I take it your goal isn’t to change that, but to improve the situation where it unfortunately happens. Exactly. We are trying to improve the situation when that happens. If possible, we'd like the situation to be avoided -- e.g., if you want dynamic prefixes, do so in an ordered way. But since we cannot rely on others behaving nicely, we want to make hosts more robust to these scenarios. > (Which of course might encourage ISPs to do just that.) > >>>>> If you want something like session survivability, >>>>> that’s not a trivial problem to solve. >>>> >>>> Not sure what you mean by "session survivability" >>> >>> Try to keep a TCP session active while changing addresses. >> >> Of course that's not what we're trying to solve here. > > No, but it is important to understand the implications of your work. Not sure what you mean. You mean the goal its not clearly stated? Something else? >>>>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so. >>>> >>>> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes? >>>> >>>> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages >>>> are soft errors. And it would be a huge mistake (and huge >>>> vulnerability!) to behave otherwise. >>> >>> It’s a strong hint to the host stack to pick a different source address. >> >> You said "deprecate the invalid prefix if it has information to do so." >> -- selecting a different address is a very different thing than >> deprecating an address. In fact, for connection-less protocols that >> might not even make sense -- since it implies resending stuff that you >> might not even be able to resend (send buffer is gone). > > No, I didn’t say that. > I said the network will deprecate the prefix if it has information to do. I.e. send a PIO with preferred lifetime = 0. Who would be sending that, and in response to what? > And that the network will respond with a type 5 destination unreachable, if an invalid source address is used. See BCP38. Again: does this happen *in practice*? Besides: fgont@laptop:~$ curl -s https://tools.ietf.org/rfc/bcp/bcp38.txt | grep -P '(icmp|ICMP)' Similar attacks have been attempted using UDP and ICMP flooding. domain to reach their systems. The latter attack (ICMP flooding), >> Besides, >> >> * You are assuming somebody will send an ICMPs. But they may not. > > Is it interesting discussion assumptions that aren’t part of the specifications? > >> >> * You are assuming that if they do, they will send code 5. But they may not. > > See above. > >> >> * You are assuming that code 5 is an indication of wrong address... but >> it may be an indication of incorrect route. > > No. If the address failed ingress/egress policy you may have picked the wrong address or e.g. default route. >> * You are assuming that nodes will process icmp code 5 in one specific >> way. I don't know of any implementation that behaves in the way you >> describe. > > Hosts can improve. > My point was that it isn’t obivous that very much more can be done from the network side. CPEs can be required to advertise previously-advertised prefixes that are not valid anymore. And hosts can be improved so that they can detect that a prefix is no longer advertised, and hence shouldn't be used -- or, at the very least, should no longer be preferred. >> One (more complex) way to achive this would be to e.g., wait for N * >> ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at >> least M RAs with PIOs have been received, but none of them contain PIOs >> for the (now invalid) prefix, deprecate the prefix. >> >> The solution we currently propose in the I-D is simpler, and just >> involves one additional bit per prefix in the local data structures. >> >> For a sample scenario, please check Appendix B of our draft. THe idea is >> simple: if two consecutive RAs with PIOs don't contain the >> previously-advertised prefix, un-prefer addresses for such prefix. >> Subsequently, once addresses have already been un-preferred, if you >> receive two additional RAs with PIOs that don't advertise the >> previously-advertised prefix, remove (invalidate) the corresponding >> addresses. >> >> So, after two RAs, the lagging addresses are not preferred anymore. >> After four RAs, you get rid of them. > > So the proposal is that an address is marked as not preferred after anywhere between 6 and 20 minutes? No. It is marked as not preferred in less than one minute (RFC4861): For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it becomes an advertising interface, if the randomly chosen interval is greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for the initial advertisements increases the likelihood of a router being discovered quickly when it first becomes available, in the presence of possible packet loss. > I am not saying that we can’t and shouldn’t improve on SLAAC… but I think we can do better. And existing heuristics are better than this. What are the existing heuristics? If there was such a thing, there shouldn't be a problem in the first place. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [v6ops] A common problem with SLAAC in "renumberi… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Tassos Chatzithomaoglou
- Re: [v6ops] A common problem with SLAAC in "renum… Bernie Volz (volz)
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… Sander Steffann
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Sander Steffann
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… Philip Homburg
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Tarko Tikan
- Re: [v6ops] A common problem with SLAAC in "renum… Philip Homburg
- Re: [v6ops] A common problem with SLAAC in "renum… Tarko Tikan
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Sander Steffann
- Re: [v6ops] A common problem with SLAAC in "renum… Sander Steffann
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Philip Homburg
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Fred Baker
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… Joel M. Halpern
- Re: [v6ops] A common problem with SLAAC in "renum… Nick Hilliard
- Re: [v6ops] A common problem with SLAAC in "renum… Michael Richardson
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… Brian E Carpenter
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Christian Huitema
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Michael Richardson
- Re: [v6ops] A common problem with SLAAC in "renum… Michael Richardson
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Christian Huitema
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Andrews
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Christian Huitema
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Tore Anderson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Jen Linkova
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Jen Linkova
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Joel M. Halpern
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Jen Linkova
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Nick Hilliard
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… sthaug
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… j h woodyatt
- Re: [v6ops] A common problem with SLAAC in "renum… Manfredi (US), Albert E
- Re: [v6ops] A common problem with SLAAC in "renum… Nick Hilliard
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… Manfredi (US), Albert E
- Re: [v6ops] A common problem with SLAAC in "renum… Brian E Carpenter
- Re: [v6ops] A common problem with SLAAC in "renum… Lorenzo Colitti
- Re: [v6ops] A common problem with SLAAC in "renum… Manfredi (US), Albert E
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Erik Kline
- Re: [v6ops] A common problem with SLAAC in "renum… Erik Kline
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Erik Kline
- Re: [v6ops] A common problem with SLAAC in "renum… Brian E Carpenter
- Re: [v6ops] A common problem with SLAAC in "renum… j h woodyatt
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Erik Kline
- Re: [v6ops] A common problem with SLAAC in "renum… j h woodyatt
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… Tim Chown
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Timothy Winters
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Brian E Carpenter
- Re: [v6ops] A common problem with SLAAC in "renum… Manfredi (US), Albert E
- Re: [v6ops] A common problem with SLAAC in "renum… Brian E Carpenter
- Re: [v6ops] A common problem with SLAAC in "renum… Brian E Carpenter
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Gert Doering
- Re: [v6ops] A common problem with SLAAC in "renum… Manfredi (US), Albert E
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Tom Herbert
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Andrews
- Re: [v6ops] A common problem with SLAAC in "renum… Owen DeLong
- Re: [v6ops] A common problem with SLAAC in "renum… Lorenzo Colitti
- Re: [v6ops] A common problem with SLAAC in "renum… Lorenzo Colitti
- Re: [v6ops] A common problem with SLAAC in "renum… Tom Herbert
- Re: [v6ops] A common problem with SLAAC in "renum… Owen DeLong
- Re: [v6ops] A common problem with SLAAC in "renum… Tom Herbert
- Re: [v6ops] A common problem with SLAAC in "renum… JORDI PALET MARTINEZ
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- [v6ops] NAT debate (Re: A common problem with SLA… Fernando Gont
- Re: [v6ops] NAT debate (Re: A common problem with… Tom Herbert
- Re: [v6ops] NAT debate (Re: A common problem with… Kristian McColm
- Re: [v6ops] NAT debate (Re: A common problem with… Tom Herbert
- Re: [v6ops] NAT debate (Re: A common problem with… Kristian McColm
- Re: [v6ops] NAT debate (Re: A common problem with… Ca By
- Re: [v6ops] NAT debate (Re: A common problem with… Raymond Burkholder
- Re: [v6ops] NAT debate (Re: A common problem with… Kristian McColm
- [v6ops] Is addressing privacy via NAT really achi… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Christian Huitema
- Re: [v6ops] NAT debate (Re: A common problem with… Mark Smith
- [v6ops] 464XLAT -- Re: NAT debate (Re: A common p… Lencse Gábor
- Re: [v6ops] A common problem with SLAAC in "renum… Nick Hilliard
- Re: [v6ops] 464XLAT -- Re: NAT debate (Re: A comm… Ca By
- [v6ops] Stability and Resilience (was Re: A commo… Lee Howard
- Re: [v6ops] A common problem with SLAAC in "renum… Christian Huitema
- Re: [v6ops] Stability and Resilience (was Re: A c… Owen DeLong
- Re: [v6ops] Stability and Resilience (was Re: A c… Michael Richardson
- Re: [v6ops] Is addressing privacy via NAT really … Tom Herbert
- Re: [v6ops] Stability and Resilience (was Re: A c… Tim Chown
- Re: [v6ops] Stability and Resilience (was Re: A c… Timothy Winters
- Re: [v6ops] Stability and Resilience (was Re: A c… David Farmer
- Re: [v6ops] Is addressing privacy via NAT really … Ca By
- Re: [v6ops] Stability and Resilience (was Re: A c… Lee Howard
- Re: [v6ops] Stability and Resilience (was Re: A c… Lee Howard
- Re: [v6ops] Is addressing privacy via NAT really … Tom Herbert
- Re: [v6ops] Is addressing privacy via NAT really … Michael Richardson
- Re: [v6ops] Stability and Resilience (was Re: A c… David Farmer
- Re: [v6ops] Stability and Resilience (was Re: A c… Lee Howard
- Re: [v6ops] Stability and Resilience (was Re: A c… Owen DeLong
- Re: [v6ops] Is addressing privacy via NAT really … Ca By
- Re: [v6ops] Is addressing privacy via NAT really … Tom Herbert
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] Stability and Resilience (was Re: A c… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] Stability and Resilience (was Re: A c… Fernando Gont
- Re: [v6ops] Stability and Resilience (was Re: A c… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Ted Lemon
- Re: [v6ops] A common problem with SLAAC in "renum… Lee Howard
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Ted Lemon
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Lorenzo Colitti
- Re: [v6ops] A common problem with SLAAC in "renum… STARK, BARBARA H
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Tim Chown
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Tim Chown
- Re: [v6ops] A common problem with SLAAC in "renum… Ole Troan
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Mark Smith
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… Michael Richardson
- Re: [v6ops] A common problem with SLAAC in "renum… Mikael Abrahamsson
- Re: [v6ops] A common problem with SLAAC in "renum… Lorenzo Colitti
- Re: [v6ops] A common problem with SLAAC in "renum… Lorenzo Colitti
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] Is addressing privacy via NAT really … Behcet Sarikaya
- Re: [v6ops] A common problem with SLAAC in "renum… 神明達哉
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… 神明達哉
- Re: [v6ops] A common problem with SLAAC in "renum… Fernando Gont
- Re: [v6ops] A common problem with SLAAC in "renum… Owen DeLong
- Re: [v6ops] A common problem with SLAAC in "renum… Richard Patterson
- Re: [v6ops] A common problem with SLAAC in "renum… 神明達哉