RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 17 November 2020 21:48 UTC
Return-Path: <Fred.L.Templin@boeing.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 2DEBC3A0A2E for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 13:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 CEmuhLakOC55 for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 13:48:27 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5F03A0CB9 for <ipv6@ietf.org>; Tue, 17 Nov 2020 13:48:23 -0800 (PST)
Received: from localhostlocalhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AHLmHAH007218; Tue, 17 Nov 2020 16:48:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1605649701; bh=Ukqe3ZUAuwAo45LXmMQiscnXOvsplSliMaLp1ZmMo3A=; h=From:To:Subject:Date:References:In-Reply-To:From; b=We/j7wvnF0DYCyYbW8Q6Q2nXatoDF6u6p1hxgnT1B8XwSpSd1UDLUXPhahh7FtGzy QtjqjMouMW1E+mNmGdXOUMN9DDVclzQa40IIcVgrCFZ+3TNzS9mxPwjh+hUfcNiwII f8PcYZy75Ue54QHteSHR5HupLpGwRWGThmLzZnFT84XMyvkzfZ9VkrIqJnfTz267x6 anoPh5bNSx2PgARBT2igMoBLQtOeo57lpvAZ8AseEllAJgJqzRFfQZMHnt2qk+8qOw UlhYUz/e0B37k1SUA/4ptxen//8U2+DeWx7C02qyBiR83f3yQLgVoaPUhiK7xG2gIj JzbRQkxNUHokA==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AHLmD7O007187 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 17 Nov 2020 16:48:13 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 17 Nov 2020 13:48:12 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 17 Nov 2020 13:48:12 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Tony Whyman <tony.whyman@mccallumwhyman.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
Thread-Topic: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example)
Thread-Index: AQHWvSlprTHHj3CB90CSr3DKTuAghanM21Mg
Date: Tue, 17 Nov 2020 21:48:12 +0000
Message-ID: <505489b6ff0e456685d73ceba47bd574@boeing.com>
References: <202011151920.0AFJKN9U003337@mail2.mwassocs.co.uk> <3d26bffe-b6c9-4ed7-6135-a515f9902fd7@gmail.com> <m1keOTi-0000EGC@stereo.hq.phicoh.net> <CAO42Z2wZkXryhw1u5WAFdtCvXHyyz1zeM22FP_gRxjurjsG-Jw@mail.gmail.com> <CAN-Dau2XTRJpR9S=ZXOXOD6PkxLTD7KAzN-CwoGhMUmSQTp0Zg@mail.gmail.com> <91d4b7d4-5477-50c0-fb34-5e7bbfdfb253@gmail.com> <ad5ee6e1-c402-f9d4-80a2-f9f0fd5c3da5@mccallumwhyman.com> <1cb21ff2-06f5-d92c-2e50-c93b4ee425a0@gmail.com>
In-Reply-To: <1cb21ff2-06f5-d92c-2e50-c93b4ee425a0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 015812E416582B7A4DDD1DDFCC2DB335A21BA5809B003C95A672705C057F3AD12000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Tkmo0Z2PYLWsMxe5fB-AYcukFx0>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 17 Nov 2020 21:48:30 -0000
Brian, > Saying that a /60 is acceptable is assuming that things won't change > and the 16 subnets is enough for all aircraft for all time. Well, I > just looked back at the input to IPng design from a Boeing source > [RFC1687], and it doesn't even mention IPng on aircraft. (It does mention > compatibility with ICAO usage of CLNP, however.) Shows how good we > are at prediction. That document was published long before I came to Boeing, and the views expressed there have faded into the past. The aviation industry is very much interested in IPv6 now, Boeing included. Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Tuesday, November 17, 2020 1:33 PM > To: Tony Whyman <tony.whyman@mccallumwhyman.com>; ipv6@ietf.org > Subject: [EXTERNAL] Re: Extending a /64 (ATN/IPS worked example) > > This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and > know that the content is safe. > > > Tony, > > Thanks for the example; very helpful. More in line... > > On 17-Nov-20 22:26, Tony Whyman wrote: > > On 17/11/2020 03:39, Brian E Carpenter wrote: > >> Excuse front posting: > >> > >>> Whether or not the addresses used in the control systems of aircraft are announced to the Internet, it seems completely justified > to use globally unique address space to address them. > >> I completely agree. That isn't where the issue lies. It's in the proposal to include 39 non-topological bits in the routeable prefix, > which goes against 25 years of CIDR. > >> (28 years if we respect RFC1338 as the origin document.) > >> > >> Regards > >> Brian Carpenter > > > > Brian, > > > > The "39 bits" does look like the focus of your objection and perhaps the > > best way to convince you that this is the right approach is to post a > > worked example. I have hung back from doing this before if only because > > the ICAO working group is still evaluating mobility schemes that aim to > > improve on Mobile IPv6. However, a simple example using Mobile IPv6, > > with multilink extensions and Basic NEMO should be good enough to > > illustrate our logic. > > > > 1. The Home Agents > > > > The organisational model for the ATN/IPS pushes you quickly towards a > > view that each aircraft operator (e.g. airline) should be responsible > > for deploying a Home Agent for their aircraft. They may operate their > > own Home Agent or outsource it to one of the industry's service > > providers. Basically, they pay for the Home Agent and are responsible > > for ensuring that their aircraft each have a Home Agent. > > Yes, that makes sense (assuming there are strong provisions for what > happens when an airline ceases operations or gets taken over, since > I assume that having an aircraft orphaned while in flight would be > unacceptable). > > > > > 2. The Home Network Prefix > > > > Each aircraft operator could individually register (e.g.) a /32 with an > > RIR for their Home Network Prefix. However, there are more than 5,000 > > airlines and if you want to have firewall rules that refer to "all > > uplink packets", an un-coordinated registration of Home Network Prefixes > > would lead to a big configuration maintenance problem for every firewall > > in the ATN/IPS. The preference has thus been to have a common ICAO > > prefix for "all aircraft MNPs" and to allocate a Home Network Prefix to > > each aircraft operator using this common prefix. > > That's a rather naive approach IMHO. Firstly, as has been pointed out, it > mismatches the entire design and history of IPv6 prefix allocation (which > regards 5000 as a very small number). Secondly, it's hard to believe that > this would be a significant part of firewall maintenance; there will surely > be a need for fine-grained configuration anyway, for what I mentioned > above: creation of new airlines, mergers, discontinuations. It certainly > wouldn't be acceptable from a security viewpoint to have a "default allow" > for any address that purports to indicate a previously unknown airline. > So how could you safely have fewer than 5000 firewall rules that are > continuously subject to updates? > > > Our addressing plan allocates a /36 to each aircraft operator for use as > > a Home Network Prefix, including the 15 bits used to identify each > > airline. On paper, this is a more efficient use of the IPv6 address > > space than a free for all, which should be seen as a potential benefit > > of an ICAO administered scheme. > > On paper it's 2^15 = 32,768 prefixes where 5000 would do; not that those are > very large numbers in IPv6 terms. > > > The /36 Home Network Prefixes should be normal routeable prefixes > > leading to the aircraft operator's Home Network. I would expect that > > each is advertised in the NLRI of a stable BGP route (leading to the > > Home Network) with aggregation to the common ICAO prefix at the ATN > > boundaries. > > If I understand that correctly, it would recreate what I've always > seen as the main problem in the model for LISP/Internet interworking, > namely a finite number of bottleneck routers. (And that's regardless > of where you put the MNP bits.) If you don't have such a shared > prefix, those bottlenecks disappear. > > > 3. Binding Updates > > > > This should be a textbook approach. Aircraft use Mobile IPv6 Binding > > Updates to register each currently active care-of address and their MNP > > with their Home Agent. > > As I understand it you want one home address for each active address > on each aircraft? That's to say that if 500 devices were active on > a given aircraft, they'd each need their own home address? > > > 4. Forwarding to the Aircraft > > > > An uplink packet addressed to an MNP relative destination address should > > be routed to the Home Network for the aircraft's aircraft operator and > > picked up by the Home Agent. > > > > The Home Agent can now match registered MNPs against the packet's > > destination address, select the care-of address, encapsulate and forward > > the packet to the selected care-of address. The packet is received by > > the airborne router, decapsulated and forward to its final destination > > using normal forwarding procedures. > > But that can work equally well if the MNP bits are in (say) bits 64 to 63+n. > They don't need to be in the topology bits at all. > > > > > Analysis > > ------------ > > > > The MNP is necessarily non-topological to the underlying internet, which > > is why you need something like Mobile IPv6 to make the whole thing work. > > The only thing outstanding in the above is "how long a prefix is the MNP"? > > > > Each MNP will be allocated using the aircraft's Home Network Prefix. The > > rest of the MNP is just going to be a number n-bits in length. There is > > no useful topological information that you can put there. > > Exactly right, which is why I think the correct design is to put those > bits in the non-topological part of the address. > > > I believe that American Airlines currently has the largest fleet with > > about 1,300 aircraft. You would need a minimum of 11 bits for this fleet > > - rounded up to 12 for a nibble boundary. > > > > You recently sent me a reference to a paper on prefix management and I > > presume that you would favour an approach where the Home Agent was > > responsible for automatically allocating an MNP to each aircraft, > > perhaps using DHCPv6 PD embedded in Mobile IP exchanges. > > No, I can see why you want it to be a constant. But precisely because > it's a constant, it should not be in the topology bits. > > > However, there is usually a strong preference in this environment for > > static allocations configured into (in this case) the aircraft. This is > > all down to limiting the number of possible hazards, providing proofs of > > correction configuration and so on. The regulators and safety > > authorities have the last call in this area. > > > > A Home Agent based allocation scheme would also cause problems with our > > protocol gateways to legacy systems as there would need to be a > > mechanism to map these allocations to ICAO 24-bit aircraft ids - > > probably requiring some protocol to export the allocations from each > > Home Agent and then copy them to the protocol gateways. > > > > The options for MNP allocation can be written down as: > > > > 1. Home Agent Allocation of a /48 (Home Network Prefix plus 12 bit > > aircraft identifier). > > > > 2. Airline Allocation of a /48 (Home Network Prefix plus 12 bit aircraft > > identifier) and configuration of the new 12 bit aircraft identifier into > > the Aircraft's Personality Module. > > > > 3. Allocation of a /60 (Home Network Prefix plus the ICAO 24-bit > > identifier already configured in the Aircraft's Personality Module). > > You're missing: > > 4. Allocation of whatever CIDR prefix is suitable plus embedding > the ICAO 24-bit identifier in all on-board Interface IDs. > > (I'm not saying that works out of the box with passengers' > laptops and smartphones.) > > > The ICAO working group has gone for option 3 on the grounds that a > > 24-bit identifier already exists and configured into the aircraft. It's > > as near as you get to free of charge. It also supports our protocol > > gateways to legacy systems without the need for mapping tables. Option 2 > > adds extra cost in terms of configuration management and forces a lookup > > table into our protocol gateways to legacy systems and a need to provide > > for timely update of this lookup table. Option 1 introduces extra > > hazards due to additional protocol, ensuring that re-numbering does not > > take place during flight and an additional certification cost for Home > > Agents - and it also forces a lookup table into our protocol gateways to > > legacy systems plus a means to communicate the allocated MNPs. > > > > For us, Option 3 was a "no brainer" on both cost and engineering > > considerations. A /60 is acceptable for an aircraft, and no one can > > identify a use case where a /60 won't do and a /48 is required. If you > > really think that this wasteful of a scarce resource then have a word > > with my ISP and ask them why they give me a /48 for a residential > > broadband service when all I need is a /64. > > Saying that a /60 is acceptable is assuming that things won't change > and the 16 subnets is enough for all aircraft for all time. Well, I > just looked back at the input to IPng design from a Boeing source > [RFC1687], and it doesn't even mention IPng on aircraft. (It does mention > compatibility with ICAO usage of CLNP, however.) Shows how good we > are at prediction. > > But that issue goes away if airlines just get a prefix the same way as > any other enterprise, with the ability to get another one later if > required. > > > > > Hopefully this explains a few thing. > > It does. It also convinces me that this discussion belongs in > the IETF Routing Area. > > Regards > Brian > > > > Regards > > > > Tony Whyman, MWA > > > > > >> On 17-Nov-20 15:55, David Farmer wrote: > >>> On Sun, Nov 15, 2020 at 2:56 PM Mark Smith <markzzzsmith@gmail.com <mailto:markzzzsmith@gmail.com>> wrote: > >>> > >>> > >>> On Mon, 16 Nov 2020, 07:19 Philip Homburg, <pch-ipv6-ietf-6@u-1.phicoh.com <mailto:pch-ipv6-ietf-6@u-1.phicoh.com>> > wrote: > >>> > >>> > Again, there are 35 trillion /48s in 2000::/3. How many would you > >>> > need? > >>> > >>> It gets tight when you want the prefix to contain 39 bits to number around > >>> half a million planes. > >>> > >>> > >>> Why are half a million planes going to be on the Internet? > >>> > >>> > >>> Being on the Internet is not the only justification for the use of globally unique address space. > >>> > >>> You mention that airplanes can fall out of the sky, it would be really bad if an airplane every fell out of the sky, or collided with > another airplane, because of an address conflict. The proper used globally unique registered address space makes such a conflict > almost impossible. Where the use of ULA makes such addressing conflicts statistically possible, even if unlikely. With half a million > aircraft and the potential consequences of an address conflict, the ULA random selection algorithm is probably not a good idea for this > use case. > >>> > >>> Whether or not the addresses used in the control systems of aircraft are announced to the Internet, it seems completely justified > to use globally unique address space to address them. Further, a single very large allocation something like a /16 or more to the > international coordinating body for the aircraft industry, allowing them to make sub-allocations to aircraft operators, airport operators, > navigational aid operators, etc... seems like a quite reasonable address management scheme to me. > >>> > >>> There are several ways to accomplish this; the IETF could make a special allocation, a global policy could be coordinated through > the RIRs and the ICANN ASO, or the entity could approach one of the RIRs for an allocation directly. As a past member of the ARIN AC, > I know for a fact that ARIN IPv6 policy explicitly contemplates LIRs that are not necessarily connected to the Internet, and > contemplates generous initial allocations of up to a /16 for LIRs when justified. Further, ARIN uses a sparse allocation methodology, > reserving at least an additional nibble of address space for future expansion. > >>> > >>> Honestly, given the importance of the use case discussed, I don't see the controversy, the allocation of a large address space > allowing for the assignment of /48s or /56s to aircraft and /48 or larger to airports seems easily justified, and allocating it out of > something other than 2000/3 seems quite reasonable as well, which would require IETF action. Further, the use of IIDs other than /64 > is completely unnecessary. > >>> > >>> Thinking even more broadly it might not be a bad idea to allocate a whole new /4 for transportation automation to cover aircraft, > cars, trucks, intelligent roadways, etc... > >>> > >>> 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 > >> -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > 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 > --------------------------------------------------------------------
- Extending a /64 otroan
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 otroan
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Ca By
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 otroan
- Re: Extending a /64 JORDI PALET MARTINEZ
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: [EXTERNAL] Re: Extending a /64 Mark Smith
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Extending a /64 Brian E Carpenter
- Re: [EXTERNAL] Re: Extending a /64 Gyan Mishra
- Re: [EXTERNAL] Re: Extending a /64 Mark Smith
- Re: Extending a /64 otroan
- Re: [EXTERNAL] Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: [EXTERNAL] Extending a /64 Gyan Mishra
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 JORDI PALET MARTINEZ
- Re: Extending a /64 Pascal Thubert (pthubert)
- Re: Extending a /64 George Michaelson
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Christopher Morrow
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 otroan
- Re: Extending a /64 Christopher Morrow
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mikael Abrahamsson
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mikael Abrahamsson
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 otroan
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 S Moonesamy
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 JORDI PALET MARTINEZ
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Extending a /64 Gyan Mishra
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 JORDI PALET MARTINEZ
- Re: Extending a /64 Simon Hobson
- Re: Extending a /64 Joel M. Halpern
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Joel M. Halpern
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Alexandre Petrescu
- RE: Extending a /64 Da Silva, Saulo
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Templin (US), Fred L
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Alexandre Petrescu
- Re: Extending a /64 Behcet Sarikaya
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Joel M. Halpern
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Templin (US), Fred L
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Templin (US), Fred L
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Tony Whyman
- RE: Extending a /64 Da Silva, Saulo
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Mark Smith
- Why this is broken [was Re: Extending a /64] Brian E Carpenter
- RE: [EXTERNAL] Why this is broken [was Re: Extend… Templin (US), Fred L
- Re: [EXTERNAL] Why this is broken [was Re: Extend… Matthew Petach
- Re: Why this is broken [was Re: Extending a /64] Tony Whyman
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Why this is broken [was Re: Extending a /64] Brian E Carpenter
- Re: Extending a /64 David Farmer
- Re: Extending a /64 Brian E Carpenter
- Re: Extending a /64 (ATN/IPS worked example) Tony Whyman
- Re: Extending a /64 Tony Whyman
- Re: Why this is broken [was Re: Extending a /64] Tony Whyman
- Re: Extending a /64 (ATN/IPS worked example) Philip Homburg
- Re: Extending a /64 (ATN/IPS worked example) Tony Whyman
- Re: Extending a /64 David Farmer
- Re: Extending a /64 (ATN/IPS worked example) Philip Homburg
- Re: Extending a /64 Tony Whyman
- Re: [EXTERNAL] Why this is broken [was Re: Extend… Behcet Sarikaya
- Re: Extending a /64 Simon Hobson
- Re: Cellphones in aircraft [was: Why this is brok… Simon Hobson
- RE: [EXTERNAL] Why this is broken [was Re: Extend… Templin (US), Fred L
- Re: [EXTERNAL] Why this is broken [was Re: Extend… Behcet Sarikaya
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- Re: Why this is broken [was Re: Extending a /64] Matthew Petach
- RE: [EXTERNAL] Re: Why this is broken [was Re: Ex… Templin (US), Fred L
- Re: Extending a /64 (ATN/IPS worked example) Templin (US), Fred L
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- Re: Extending a /64 (ATN/IPS worked example) Templin (US), Fred L
- Re: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Brian E Carpenter
- Re: Extending a /64 (ATN/IPS worked example) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Manfredi (US), Albert E
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- Re: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Philip Homburg
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Manfredi (US), Albert E
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- RE: [EXTERNAL] Re: Extending a /64 (ATN/IPS worke… Templin (US), Fred L
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 (ATN/IPS worked example) Michael Richardson
- Re: Extending a /64 (ATN/IPS worked example) Michael Richardson
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 (The most welcome comment) Tony Whyman
- Re: Why this is broken [was Re: Extending a /64] Behcet Sarikaya
- Re: Extending a /64 (The most welcome comment) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (The most welc… Manfredi (US), Albert E
- Re: Extending a /64 Michael Richardson
- Re: Extending a /64 (The most welcome comment) Templin (US), Fred L
- RE: Extending a /64 (The most welcome comment) Manfredi (US), Albert E
- Re: Extending a /64 (The most welcome comment) Brian E Carpenter
- RE: [EXTERNAL] Re: Extending a /64 (The most welc… Templin (US), Fred L
- Re: Extending a /64 (The most welcome comment) David Farmer
- Re: Extending a /64 Michael Richardson
- Re: Why this is broken [was Re: Extending a /64] Michael Richardson
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Mark Smith
- Re: [EXTERNAL] Re: Extending a /64 (The most welc… Tony Whyman
- RE: [EXTERNAL] Re: Extending a /64 (The most welc… Pascal Thubert (pthubert)
- Re: [EXTERNAL] Re: Extending a /64 (The most welc… Tony Whyman
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Tony Whyman
- Re: [**EXTERNAL**] Re: Extending a /64 Mudric, Dusan
- Re: [**EXTERNAL**] Re: Extending a /64 Tony Whyman
- Re: Extending a /64 Nick Hilliard
- Re: Extending a /64 (The most welcome comment) Templin (US), Fred L
- Re: [**EXTERNAL**] Re: Extending a /64 tom petch
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Nick Hilliard
- RE: [EXTERNAL] Re: Extending a /64 Manfredi (US), Albert E
- Re: Extending a /64 Mark Smith
- Re: Extending a /64 Philip Homburg
- Re: Extending a /64 Nick Hilliard