Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Lorenzo Colitti <lorenzo@google.com> Tue, 26 February 2019 14:28 UTC
Return-Path: <lorenzo@google.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 E2D77130EC1 for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2019 06:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 K9KpuafkZipu for <v6ops@ietfa.amsl.com>; Tue, 26 Feb 2019 06:28:00 -0800 (PST)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C8F130E82 for <v6ops@ietf.org>; Tue, 26 Feb 2019 06:28:00 -0800 (PST)
Received: by mail-it1-x12c.google.com with SMTP id e24so4080369itl.1 for <v6ops@ietf.org>; Tue, 26 Feb 2019 06:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EpNdkqKF1Ay82/hX/81toels0zMdnuJtj1d5EM5nSC0=; b=C7OITWFrjJWfvHOKOP+2Xb3AviHdFUUVtz9k2ZouKl5A6FlaTD52ajvKSMI75yWwho L9X9LK3VmyaDah0fGbsl+UYsWOS3F/MdmRMIsCpIuH7OLWxbEoHhOCJBr70u+RKcruUs 5v7T/egnAxqN1QgvxElRUj6GX57moPDtohTSco0EVEB3PTbVGSykX+zAWlqIU95X7d07 RLOyWgNVzF21X1lk5/IzEWM/i19YkLbhjST+4rOUE6NFNdiAciPWEszdF0Vu76X2vN41 +rn1U22Nm7XeuKJpbvfjgH7uR/IzluqGIwzllrUPLHJvWK7ZMGgrrGvu0m1+KkbDpJcx mlag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EpNdkqKF1Ay82/hX/81toels0zMdnuJtj1d5EM5nSC0=; b=ZXB3hsH5UPzi0jzTGK3atkM2zUBvNBsEIRJLbP7sgNFdeG9XcHllIwSxX5MOUfHFOJ lSAXpAPISa77wI7fRpEnOwJqnHE62Q2tFpdhr9pdXhQbGhyTmngdVWw4u6vJGtBpooKu 6JFE0KeexAqxwk8GA4+AZLCWtyQBjP1KcGyuHd4vf9pTNbx1wHSs7Kzq01KHwTnYBqPL rlMTuNuViyPE/03l0WCD67s/3YtmHltuu03cot9X0gzC9swYAiBNB2LxDo42VGU4wDmv tSD6uY0Ez91CQLDmy7tm4hMT7UF4WWVUfA4yx+lO5wffUyvXl6NyQH1hV5PC1LW/XrGC Nlhg==
X-Gm-Message-State: AHQUAuactqhxlzBJOUS8DE89Ts3zfaGPSNft6MFtPhV6JG8sNyxAXG45 eLcGBrPkIhf9hKVdz5bbu8jhZ95BydDo2ZDtHkLjAQ==
X-Google-Smtp-Source: AHgI3IY4fFYboPDJ7sN+h8NlerPHx/Phrntw9jb6phWsIZxbLaPKzBIz/H6cEDdFfeQBrVGCiU0S3roSzgYgrhaHw0M=
X-Received: by 2002:a02:10c9:: with SMTP id 192mr650232jay.51.1551191279569; Tue, 26 Feb 2019 06:27:59 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <CAHL_VyD34V=TRcsCp0DOO9HJNHyy5xkiMQ_cZoBa7zTE4fe5OA@mail.gmail.com> <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com> <FB8B77EE-CC16-4418-BB5E-D44EE66D6B72@jisc.ac.uk> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <F4F90B88-3EED-4AF2-82FE-5F1023A05605@employees.org> <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com> <CAO42Z2y+poR1cHp=wxPDs6umu80uyN94r=bh+NOw2HdFQYZMNg@mail.gmail.com>
In-Reply-To: <CAO42Z2y+poR1cHp=wxPDs6umu80uyN94r=bh+NOw2HdFQYZMNg@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 26 Feb 2019 23:27:46 +0900
Message-ID: <CAKD1Yr1fe4MX0ySuwTipSGtVaDxA9vVeR1i3ES2yw3ir=2NMdw@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, v6ops list <v6ops@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Type: multipart/alternative; boundary="000000000000330c2a0582ccdddc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AZawYrbn3rGRFUHITJ_ajsD53fo>
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: Tue, 26 Feb 2019 14:28:04 -0000
FWIW, from a host implementer perspective, DecrementLifetimes is a bad idea since it makes it harder to drop duplicate RAs in firmware and thus has substantial battery impact. True story: many ISP routers use a maximum advertisement interval of 3 seconds in order to fix unreachability and IPv6 brokenness problems. In order to avoid draining the battery after 12 hours of this, phone manufacturers reacted by either dropping all RAs (or even all IPv6 packets!) when the screen is off, or putting RA filtering in firmware. Then some routers decided to use DecrementLifetimes as well. Firmware RA filtering couldn't match the RAs any more and the phone manufacturers probably reacted by dropping all RAs again. In order to fix this problem on Android we had to write a bytecode interpreter and get wifi chipset manufacturers to insert it into their firmware so we could push filtering rules to the chipset at runtime. Many chipset manufacturers still haven't adopted this though. Please don't do this if you care about mobile devices having correct IPv6 implementations and acceptable battery life. On Tue, Feb 26, 2019 at 8:09 PM Mark Smith <markzzzsmith@gmail.com> wrote: > > > On Tue., 26 Feb. 2019, 22:00 Fernando Gont, <fgont@si6networks.com> wrote: > >> On 26/2/19 07:13, Ole Troan wrote: >> > Fernando, >> > >> >>>> On 25 Feb 2019, at 18:36, Fernando Gont <fgont@si6networks.com> >> wrote: >> >>>> >> >>>> On 25/2/19 07:32, Richard Patterson wrote: >> >>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <fernando@gont.com.ar> >> wrote: >> >>>>> >> >>>>>> * As per RFC4862, it turns out that you cannot remove a stale >> prefix vy >> >>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current >> standards, >> >>>>>> not even the CPEs can (even if they wanted to) do something to fix >> the >> >>>>>> problem. >> >>>>> >> >>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but >> >>>>> the Preferred Lifetime can. So we can't invalidate the prefix, but >> we >> >>>>> can deprecate it so it's not used for new outbound sessions. This >> is >> >>>>> what we've implemented in our CPEs, after an unavoidable change in >> >>>>> prefix, and it seems to have mitigated (or reduced the impact of) >> the >> >>>>> issue. >> >>>> >> >>>> Agreed. That said, with the current default lifetime values, things >> >>>> become tricky: >> >>>> At least in theory, you should be sending such RAs for "Valid >> Lifetime" >> >>>> seconds. With a default of one month, that means that, in theory, you >> >>>> should be sending such RAs for a month. And if there are multiple >> >>>> crash-and-reboot events, you should advertise each of the stale >> >>>> prefixes. (I assume the CPE just records the last one) >> >>> >> >>> When / where was the default Valid Lifetime chosen to be one month? >> >> >> >> Section 6.2.1 of RFC 4861: >> >> >> >> AdvPrefixList >> >> A list of prefixes to be placed in Prefix >> >> Information options in Router Advertisement >> >> messages sent from the interface. >> >> >> >> Default: all prefixes that the router advertises >> >> via routing protocols as being on-link for the >> >> interface from which the advertisement is sent. >> >> The link-local prefix SHOULD NOT be included in the >> >> list of advertised prefixes. >> >> >> >> Each prefix has an associated: >> >> >> >> AdvValidLifetime >> >> The value to be placed in the Valid >> >> Lifetime in the Prefix Information option, >> >> in seconds. The designated value of all >> >> 1's (0xffffffff) represents infinity. >> >> Implementations MAY allow AdvValidLifetime >> >> to be specified in two ways: >> >> >> >> - a time that decrements in real time, >> >> that is, one that will result in a >> >> Lifetime of zero at the specified time >> >> in the future, or >> >> >> >> - a fixed time that stays the same in >> >> consecutive advertisements. >> >> >> >> Default: 2592000 seconds (30 days), fixed >> >> (i.e., stays the same in consecutive >> >> advertisements). >> > >> > >> > Red herring. >> > >> > RA lifetimes cannot be longer than the DHCP PD lifetimes. >> >> I don't disagree with you. >> >> >> > In the DHCP PD case they should also be counted down in real time. >> > And the lifetimes can be dynamically adjusted. >> >> They should. However, quite frequently the DHCPv6-PD part is a different >> piece of software from the ra{d,dvd} part. Both pieces are glued by some >> script, and the lifetime is *not* dynamically adjusted. >> > > There is a knob in 'radvd' to do and suit that, the PD triggered/driven > script just needs to do a bit of radvd.conf modification, stopping, > starting, and signalling. > > > *DecrementLifetimes* *on*|*off* > > This option causes radvd to decrement the values of the preferred and > valid lifetimes for the prefix over time. The lifetimes are decremented by > the number of seconds since the last RA.. If radvd receives a SIGUSR1 > signal, it will reset the values of the preferred and valid lifetimes back > to the initial values used by radvd when it started. If radvd never > receives a SIGUSR1 signal, it will continue to decrement the lifetimes > until the preferred lifetime reaches zero. After a final RA with a zero > value preferred lifetime, radvd will cease to announce the prefix. If a > SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then > re-appear in the RAs. > > This option is intended to be used in conjunction with a DHCPv6 client > that is using the Identity Association for Prefix Delegation (IA_PD) option > to acquire a prefix from a Delegating Router for use by a Requesting > Router. In this scenario, the prefix(es) from within the delegated prefix > that are announced by radvd would age in parallel with and at the same rate > as the delegated prefix, and expire at approximately the same time, if the > delegated prefix's life isn't extended. > > See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol > (DHCP) version 6". > > Default: off > > >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- [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… 神明達哉