Re: [IPv6] ULA vs. 1918
Ted Lemon <mellon@fugue.com> Fri, 16 June 2023 17:19 UTC
Return-Path: <mellon@fugue.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8E3C14F693 for <ipv6@ietfa.amsl.com>; Fri, 16 Jun 2023 10:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20221208.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWLtKLZdO5Mx for <ipv6@ietfa.amsl.com>; Fri, 16 Jun 2023 10:19:11 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0123C14F747 for <ipv6@ietf.org>; Fri, 16 Jun 2023 10:16:27 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id af79cd13be357-7620e5f3428so100967285a.1 for <ipv6@ietf.org>; Fri, 16 Jun 2023 10:16:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20221208.gappssmtp.com; s=20221208; t=1686935786; x=1689527786; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dOkjrLabeAlWdd7w9W5jza+9C84XU0xitHpx3nTlsJE=; b=D7eQ3rPg+Q3RP5A91S5mxnIjVqsn5jBfSmpWFJx3jhg/pvuYwack8g4PMhYLInW0lz kbz3INoe418muiMSnSDRdOwR3GXe0LtP30AQS5W0rjZURRytkQtL7kz3vS8cxUX/a1po JJJcnZAu9zA88LPtbKIkznsD2ML/3IqsBEwcvMSdmqw0reF3u7U/PRXbIT1LE5uIcx+j gi5RiFHK6KPOt+lFU4RIhj1Kk5MAT+xxGCsaDJN+WTqJEHcdK5SF0WVTgM9y37LXdisn P/MHe/MPNevviFTL0vXg4VHt1aaCD0cROZIDgFfSRfcH69KMp31JXeje9UBbvv7XZWXq vi+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686935786; x=1689527786; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dOkjrLabeAlWdd7w9W5jza+9C84XU0xitHpx3nTlsJE=; b=IKoyCaYRg57yR9ax76fyo0fVTi83pbBq0NaChGQPlcJtrZcuYFZ8zRzRseCZfkMG8Y j03ViyM7emkwJeoX0TxG7PkKei06ynJjLpCl11dp7+49u/FOmviDtml/EyzHpRj9/JY4 E4hRNheRpg6qka1SxRdU3cFuon/X6TnnvpaaEXYLD+eqbchYQN7+2MiVxnzEVj5/sInh +ThSNldg7/NEJVUr50QEzEhUFYwQ9oBVoKwcjxXcASf0DuCtR1hM6MFV5bKnWb+o310I xX4QBhTAy+PlnYXQV3kh+XjPpjwLtRnsqbG3o77HkEp17+uqfYWmkxgIrxtbDI/25HkK eiiQ==
X-Gm-Message-State: AC+VfDzrIyTulAoi6MZzoqNUkb4iIYJrTyUBp4vjrtzbzD5YqmwxqG/X NaSXp3V+jOsXaiwEXBmluXDB5dwtUwXWinlYnO2uNw==
X-Google-Smtp-Source: ACHHUZ67Zkzfp9BQDsJRc68v5aUsq9STvlPy50HGR30c1JEv1KyYIGUpCdxet1gWziF0o/6aB2gemuuq9Ups32AOYEI=
X-Received: by 2002:a05:6214:250e:b0:5b5:9c2:8c29 with SMTP id gf14-20020a056214250e00b005b509c28c29mr3838327qvb.12.1686935786386; Fri, 16 Jun 2023 10:16:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAJU8_nW36iEWvYHu6qAGvnEKeJ1P1w4BLov+VdSeZ06XLFXDRA@mail.gmail.com> <252E7296-D071-4E2C-971C-63E18694ADB8@isc.org> <CO1PR11MB488198C7174F42A6027656B4D85AA@CO1PR11MB4881.namprd11.prod.outlook.com> <2727C342-C0C4-42E5-B75D-51174FB7F59E@isc.org> <CO1PR11MB488139AB1EC0F8D15184F6D0D85AA@CO1PR11MB4881.namprd11.prod.outlook.com> <CAN-Dau2zjmU0TXEDJyc52W=TiHXAhjnzwAqtEcpE469buH7prQ@mail.gmail.com> <24af315f-f096-cbc5-82e3-984070825541@gmail.com> <CAN-Dau3745bRSQS_Bgsb9yp0M-GK8wjToQLN9qf9PpiA=quBmQ@mail.gmail.com> <54d56b6a-1934-33fe-a8b5-e2b5408abf19@gmail.com> <DAFB73BA-D993-4957-A5A5-0B9D53E89AED@cisco.com> <99c35b98-71e3-f304-02df-0ba849220392@gmail.com> <FE8A0C37-0480-4D68-8343-B05C859BC2F9@cisco.com> <CAPt1N1=TYVbaYk1T-3RzVp+n-Uqmtmvkr=SxG=E-QbOuaEaOHA@mail.gmail.com> <CO1PR11MB48812878301CDDC2CA8D277DD858A@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB48812878301CDDC2CA8D277DD858A@CO1PR11MB4881.namprd11.prod.outlook.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 16 Jun 2023 13:15:50 -0400
Message-ID: <CAPt1N1=xgewgdMVLqgiYSPWR=htBYaWLS41vJfdxFLYmEwEd1g@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e8d9505fe4258f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YsF8iL36vPhZIJ5wWCUFFdwxs_M>
Subject: Re: [IPv6] ULA vs. 1918
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jun 2023 17:19:15 -0000
Okay, but it seems like there's no problem then, since the node is ULA-only. It's only when you number the node with a GUA and publish it that it becomes reachable. So, from an operational perspective, what is the use case you are thinking of where this is a problem in a practical sense? On Fri, Jun 16, 2023 at 11:12 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Ted > > packets to/from the ULA can only be injected within the ULA domain of > routability. > This creates an isolation against external attackers which have to be > inside or use a trojan to attack an ULA only node. > > regards, > > Pascal > ------------------------------ > *De :* Ted Lemon <mellon@fugue.com> > *Envoyé :* vendredi 16 juin 2023 16:53 > *À :* Pascal Thubert (pthubert) <pthubert@cisco.com> > *Cc :* Brian E Carpenter <brian.e.carpenter@gmail.com>; ipv6@ietf.org < > ipv6@ietf.org> > *Objet :* Re: [IPv6] ULA vs. 1918 > > What do you mean by “secure” here! > > Op vr 16 jun 2023 om 03:02 schreef Pascal Thubert (pthubert) <pthubert= > 40cisco.com@dmarc.ietf.org> > > Hello Brian > > If I have a ULA and my destination has a ULA and routing enables > connectivity between the 2, ULA to ULA seems to be the most secured choice > (because there’s some control on the diameter where an attacker can > operate). > > But then how does my stack know? Sure, routing does to a point (default > routes obfuscate). So I could leave it to trial and error / eyeballs. But > isn’t that a demonstration that the information available at the stack is > lacking? > > What we want is the stack to know which prefixes a ULA can reach from the > routing standpoint, and if an ULA can reach a prefix, allow to prefer a ULA. > > The ULA to ULA routability could be expected / inferred within a 48, but > my point above is that it’s doubly a mistake to resort on that. > > I’ll add that outside the 48 boundary, ULA longest match is not your > friend. If you have 2 ULAs a and b and a destination c outside a’s and b’s > 48s, but a longer bitwise match with b, does that mean anything about which > of a or b can be routed to c? Ne. > > This is why for each PIO of an ULA there should be a train of prefixes > that an address formed from the address in that PIO can reach, with a > preference (vs other PiOs) That’s the only way to unleash the power of ULAs. > > Note along that vein: there’s no point making GUA prefixes special in that > logic. If the ULA can reach a GUA, then the ULA is still a more secure > source address. Placing a GUA in the train with a preference should be > acceptable. For the return path, the GUA should assume symmetrical > routability: if the ULA packet reaches me I can reach it back (because it > is hopefully filtered at the site boundary). > > IOW we could consider RIO as the router-level “the originating router can > reach this destination prefix with this preference “ and a RIO-prime > attached to a PIO would be the source address-level “a source address > formed from the prefix in the PIO above can reach this destination prefix > with this preference “. This destination prefix being a global address, ULA > or GUA. > > Note that RPL use that sort of semantics very successfully. More so with > upcoming signaling in > https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/. I’m not > asking you to read the draft but it’s a good hint at how powerful the > concept of AGP can become. > > Take care, > > Pascal > > Le 15 juin 2023 à 22:40, Brian E Carpenter <brian.e.carpenter@gmail.com> > a écrit : > > On 15-Jun-23 19:38, Pascal Thubert (pthubert) wrote: > > Hello Brian > > Today the only reachability that is assumed seems to be the /64. Based on > the current standards one could assume that /48 is reachable as well but > I’d not like to case that in stone in the stacks. The /64 experience with > SLAAC should have taught us a thing or 2. > > > Routing will determine whether the whole /48 is reachable. There's not too > much we can do about that at the address selection stage. This is more a > matter of scope; and as things have evolved, the nearest thing we still > have to site-local scope is a ULA /48. I completely agree that this is > classful addressing (even link-local is classful). However, it would not be > cast in stone in the code, since it would be in a configuration table. Do > we have a better solution for the *default* behaviour? > > (There is an argument for the default table being defined by v6ops, not by > 6man.) > > Brian > > This is why I jumped in the thread. The ULA may reach a shorter > aggregation (even if to Lorenzo’s point that is not fully legal with the > current text), and it may reach other ULA prefixes. So hardcoding the /48 > is not only repeating an error of the past but also not sufficient to avoid > the need of DHCP, as soon as the network gets fancier. > > And it will. SNAC is just one example. > > I’m looking forward to seeing what the new draft proposes. I hope for a > per PIO option inspired by RIO. Basically for ULA all the access le > prefixes would be listed with a preference. > > Along the same vein I hope for another per PIO option, also inspired by > RIO, that indicates the router preference for a source address derived from > that prefix. > > Regards, > > Pascal > > Le 15 juin 2023 à 00:52, Brian E Carpenter <brian.e.carpenter@gmail.com> > a écrit : > > > On 15-Jun-23 10:33, David Farmer wrote: > > On Wed, Jun 14, 2023 at 17:01 Brian E Carpenter < > brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote: > > On 15-Jun-23 04:56, David Farmer wrote: > > > I've been thinking we should extend RFC 8028's use of a PIO with A=0 > and L=0 for choosing the first-hop router. By adding to that, if the prefix > is from the ULA range, then the host should also treat the prefix as a > Local ULA prefix from an RFC 6472 section 10.3 perspective and add it to > the table as a local ULA prefix. > > What is specific about A=L=0 in this case? Why wouldn't this apply to > any PIO in the ULA range? > > If A=1 and the prefix length isn’t 64, some people are going to have words > with you, I’m fine with it, but I’m not really looking to pick a fight > today, and those seem to be fighting words. > > > I was assuming the PIO would be for a prefix of whatever length happens to > be in use on the subnet in question (which would be indeed be 64 today). > But one can legitimately assume that if fdxx:xxxx:xxxx:yyyy::/64 is > announced, the applicable ULA prefix is fdxx:xxxx:xxxx::/48. > > > Brian > > > Also, L=1 is making a different statement about the prefix. A=L=0 isn’t > making any other statement about the prefix than it might be a ULA that the > host should treat as local and the router announcing the RA knows how to > route for. > > But it doesn’t specifically have to be A=L=0, but that is probably the > safest statement to make. > > Thanks > > -- > > =============================================== > > David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu> > > Networking & Telecommunication Services > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > > =============================================== > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
- [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Ed Horley
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Lorenzo Colitti
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 Lorenzo Colitti
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Lorenzo Colitti
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Vasilenko Eduard
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 David Farmer
- Re: [IPv6] ULA vs. 1918 Nick Buraglio
- Re: [IPv6] ULA vs. 1918 Michael Richardson
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Mark Smith
- Re: [IPv6] ULA vs. 1918 David Farmer
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 David Farmer
- Re: [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Fred Baker
- Re: [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Mark Smith
- Re: [IPv6] ULA vs. 1918 Mark Smith
- Re: [IPv6] ULA vs. 1918 Vasilenko Eduard
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- [IPv6] Developing a solution to a problem that sh… Mark Smith
- Re: [IPv6] Developing a solution to a problem tha… Mark Smith
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Timothy Winters
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Kyle Rose
- Re: [IPv6] ULA vs. 1918 Erik Nygren
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Mark Andrews
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] Developing a solution to a problem tha… Philip Homburg
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Ed Horley
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Philip Homburg
- Re: [IPv6] Developing a solution to a problem tha… Ole Troan
- Re: [IPv6] Developing a solution to a problem tha… Philip Homburg
- Re: [IPv6] Developing a solution to a problem tha… jordi.palet@consulintel.es
- Re: [IPv6] Developing a solution to a problem tha… Brian Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Ole Troan
- Re: [IPv6] Developing a solution to a problem tha… tom petch
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Ole Troan
- Re: [IPv6] Developing a solution to a problem tha… Ole Troan
- Re: [IPv6] Developing a solution to a problem tha… Ole Troan
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Philip Homburg
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Philip Homburg
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] [EXTERNAL] Re: Developing a solution t… Manfredi (US), Albert E
- Re: [IPv6] Developing a solution to a problem tha… Michael Richardson
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] Developing a solution to a problem tha… Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… David Farmer
- Re: [IPv6] Developing a solution to a problem tha… Ted Lemon
- Re: [IPv6] Developing a solution to a problem tha… Kyle Rose
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] Developing a solution to a problem tha… Brian E Carpenter
- Re: [IPv6] ULA vs. 1918 Pascal Thubert (pthubert)
- Re: [IPv6] ULA vs. 1918 Ted Lemon
- Re: [IPv6] ULA vs. 1918 Brian E Carpenter