RE: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 18 November 2020 22:27 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 EB92D3A0E52 for <ipv6@ietfa.amsl.com>; Wed, 18 Nov 2020 14:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.4
X-Spam-Level:
X-Spam-Status: No, score=-4.4 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 oeZKuYlbl6fE for <ipv6@ietfa.amsl.com>; Wed, 18 Nov 2020 14:27:31 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 1CE6B3A0E4A for <ipv6@ietf.org>; Wed, 18 Nov 2020 14:27:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AIMRON5018152; Wed, 18 Nov 2020 17:27:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1605738446; bh=3uMtYf/KwruolRon46NX2O61J0vDzaUX/Vlhzj+UNNo=; h=From:To:Subject:Date:References:In-Reply-To:From; b=k2BSxDif92CcUkGa/zwx7d4KaC6Pd2tuI0/FJFZnxBNJ7QoHIaApDd8ZXwHaGUwrB x0422ATp276M5s9VS1vGZlA6L9Syf9BWKqoVqeJJv1EUcuaCUgBAzTWraz8yeKmrgi Co4VSLHhf6GlFFrgLss4njxgYQDlcHM/QGpekifq1diD9htDoylTP2ww7KYCvuQx97 hnsdOek71/2JvLy41HDAkBIT8Yj0jq2KK6ICY4mFLavjGJbnrVtfiNYZNHq46O8QGN ck9RIyjBSha9qXp2xO84malH2M3IF4Ho0Tzx80tSgWb81nF96KjlIF0FNGGTJLsknn fj9xOZtSftf2w==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AIMRJpq018115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 18 Nov 2020 17:27:19 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 18 Nov 2020 14:27:18 -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; Wed, 18 Nov 2020 14:27:18 -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 (The most welcome comment)
Thread-Topic: [EXTERNAL] Re: Extending a /64 (The most welcome comment)
Thread-Index: Ada98MdKMzXCGnYSQvG/pg19DOSEMAAS0lQAABCmEyA=
Date: Wed, 18 Nov 2020 22:27:18 +0000
Message-ID: <f98bfc1edd38452281765f969b71f270@boeing.com>
References: <98e5403fb1dd41859ce1b57d844f1d4f@boeing.com> <f28985f8-dfd1-09cc-94f2-4e4004c6b3e2@gmail.com>
In-Reply-To: <f28985f8-dfd1-09cc-94f2-4e4004c6b3e2@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: E584D5285C291EC2577D8B61B48B8921273470D9B7BDF379C27EC8A672E0F3C92000: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/d2N4ijhuytesePmNYTwohGbL0eI>
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: Wed, 18 Nov 2020 22:27:41 -0000
Brian, > How about an ops Area draft describing how the proposal works with BGP4 and how many new BGP routes it will create? I am not well liked in ops, but if Tony is up for another document and has enjoyed the IETF "ride" thus far sure why not. What do you think, Tony? Fred > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Wednesday, November 18, 2020 2:20 PM > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Tony Whyman <tony.whyman@mccallumwhyman.com>; ipv6@ietf.org > Subject: [EXTERNAL] Re: Extending a /64 (The most welcome comment) > > Fred, > > My concern isn't about what happens inside the ICAO limited domain. What you say makes complete sense there. It's about how > these prefixes (fail to) aggregate in what we used to call the default-free zone. (RFC1888 probably would have had that problem too, > but as far as I know, nobody ever implemented it.) If there was a bgpops WG, that would be the place to discuss it. > > If the plan creates a new DFZ route for each airline, that's a negligible number in the BGP4 context. If it creates a new DFZ route for > each aircraft, that could be problematic. > > How about an ops Area draft describing how the proposal works with BGP4 and how many new BGP routes it will create? > > Regards > Brian > > On 19-Nov-20 10:27, Templin (US), Fred L wrote: > > Brian, there will be many non-airplane users of the ATN/IPS top-level IPv6 prefix > > allocation - often in fixed and non-mobile environments - and we can expect them > > to conform to CIDR conventions. We are only talking here about the airplanes, > > which are always mobile and always away from "home". > > > > I have shown how we can route their prefixes using scalable de-aggregation, > > and you seemed to concur. So, why can't we tolerate a 24-bit portion of the > > airplane's prefix that does not come from a strict CIDR hierarchy? > > > > Fred > > > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >> Sent: Wednesday, November 18, 2020 12:10 PM > >> To: Tony Whyman <tony.whyman@mccallumwhyman.com>; ipv6@ietf.org > >> Subject: [EXTERNAL] Re: Extending a /64 (The most welcome comment) > >> > >> Tony, > >> > >> I don't like the argument that people are arguing for either "purity" > >> or "perfection". That is not the issue. The issue is doing something > >> that matches how IPv6 wide-area routing actually works, and that is > >> by CIDRised prefix allocation. > >> > >> Now you have peeled back the onion to this point: > >> > >>> we have to have an addressing plan (for > >>> aircraft) that is canonical with the existing NSAP Address. > >> > >> I understand that as a perceived requirement; it's more or less why > >> we wrote RFC1888, although mapping US GOSIP addresses was the target > >> then. I don't know how the ICAO lays out its NSAPA addresses, but I > >> imagine that the aircraft ID is towards the low-order bits? > >> That's where it should be in an IPv6 address, IMNSHO. > >> > >> The current proposal seems to be limited to 16 subnets on an > >> aircraft and that is highly likely to come back and bite you. > >> > >> Regards > >> Brian Carpenter > >> > >> On 18-Nov-20 22:33, Tony Whyman wrote: > >>> On 18/11/2020 03:30, Michael Richardson wrote: > >>>> When we designed IPv6, we assumed that everyone would get some, even if they > >>>> didn't connect. > >>>> > >>>> > ULAs only have the first property. > >>>> > If a device doesn't need the second property, the device doesn't need a GUA. > >>>> > >>>> Again, what is this business of trying to ration IPv6? > >>>> Do they really need 39 bits? I don't know. > >>>> > >>>> Our entire Ipv6 architecture ENCOURAGES entities to ask for the amount of space > >>>> that they think they might need over the lifetime of their effort and NEVER > >>>> COME BACK for more. > >>>> > >>>> That's why /64 for IIDs, and /48s for every site. > >>> > >>> If there is another edition of RFC 8200 then the sentence beginning "Our > >>> entire.." should be copied to the front page of the new edition. Yes, we > >>> all get the idea that addressing plans should be as elegant as possible > >>> - but IPv4-think should have no place in this. But, perhaps the most > >>> important notion that comes through in the above is that each industry > >>> ultimately knows best when it comes to the compromises that have to be > >>> made to create an industry specific addressing plan. > >>> > >>> Over the last few days, I have been happy to try and peel away the > >>> issues that lay behind our proposed IPv6 addressing plan and to use it > >>> as an opportunity to spread understanding of the ATN/IPS and the > >>> constraints under which we are working. However, there is one point that > >>> it seems to be too difficult for some to get their head around and that > >>> is that we are not starting with a "clean sheet of paper". We have to > >>> respect the constraints that we have and sometimes arguably poor > >>> decisions that were made in the past and the result is a compromise. It > >>> will offend those who demand purity - but purity is not the objective. > >>> The objective is to deploy a working IPv6 based system. > >>> > >>> In the ICAO Working Groups, we are writing the 3rd edition of the > >>> ATN/IPS Manual. There were two earlier versions and both represent > >>> failed attempts to deliver an IPS based ATN. They failed - not > >>> necessarily for technical reasons - but because there was no business > >>> case. This is a very hard nosed industry and, unless its use is > >>> commanded by regulation, if a new technology does not deliver more > >>> passengers or raise the profit/passenger then it ain't going to happen. > >>> > >>> Even now, I am hard pressed to see any business case for an ATN/IPS > >>> replacing the venerable ATN/OSI. The ATN/OSI is a CLNP overlay on top of > >>> an IPv4 network, it works, with some limitations, and will support the > >>> current generation of applications. With nugatory upgrades it could > >>> support the next generation. Some might point to presumed cost savings > >>> by replacing CLNP with something that is industry mainstream - but the > >>> truth is that the CLNP bits are, by and large, in systems that perform > >>> functions that are unique to civil aviation, while the rest is catalogue > >>> item routers. > >>> > >>> However, looking to the long term, it will be increasingly difficult to > >>> develop new applications on the ATN/OSI base and we should seize the > >>> first opportunity that we can find to move on to an ATN/IPS. > >>> > >>> A funding window has opened up with the European Space Agency (ESA) and > >>> the EU's SESAR research programme putting in the funds to develop a > >>> prototype SATCOM service for the ATN/IPS. This should just about extend > >>> to cover initial avionics on a single aircraft type (different > >>> generations of aircraft have different communication architectures and > >>> everything has to be type approved before it can be used). The funding > >>> should also cover a protocol gateway allowing the prototype to interwork > >>> with ATC Centres i.e. to at least demonstrate an operational service > >>> using the ATN/IPS. > >>> > >>> Even stretching the funding envelope this far is optimistic. Adding in > >>> anything else like a new registration scheme for aircraft and lookup > >>> tables in the protocol gateway will kill the project financially. Yes, I > >>> know that these are not technically difficult, but when you work in an > >>> environment where every new function has to be subject to a hazard > >>> analysis, a safety case, a high end develop lifecycle and rigorous > >>> testing then, what looks like a simple function on paper, quickly gets > >>> replaced by a dollar sign followed by lots of digits. > >>> > >>> To keep this project feasible, we have to have an addressing plan (for > >>> aircraft) that is canonical with the existing NSAP Address. You may > >>> prefer purity and demand that we have a perfect addressing plan. But you > >>> are not helping. > >>> > >>> Our goal is to get a working ATN/IPS on to a single aircraft type with > >>> minimum change to the existing system. Once this has been demonstrated > >>> to be feasible and "industry mainstream" then the case can be made for > >>> rolling it out to other aircraft types and, may be, one day, even the > >>> ATC Centre's will get upgraded - but that will probably have wait until > >>> a new application provides the business case. > >>> > >>> Perhaps another aphorism that could be put on the front page of a future > >>> version of RFC 8200 is "never let the perfect be the enemy of the good". > >>> > >>> Regards > >>> > >>> Tony Whyman, MWA > >>> > >>> PS: we could always declare the ATN as a closed network and use our own > >>> addressing plan - but does not help make the "industry mainstream" case, > >>> does it. > >>> > >>> -------------------------------------------------------------------- > >>> 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