Re: Extending a /64
JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sun, 15 November 2020 22:49 UTC
Return-Path: <prvs=1588fc1146=jordi.palet@consulintel.es>
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 9C4DA3A1019 for <ipv6@ietfa.amsl.com>; Sun, 15 Nov 2020 14:49:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 5saAsgCScP0D for <ipv6@ietfa.amsl.com>; Sun, 15 Nov 2020 14:49:30 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 512113A0FD5 for <ipv6@ietf.org>; Sun, 15 Nov 2020 14:49:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1605480565; x=1606085365; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=N/mQZWNSmidnaXggclJ0yiV2H02kvFQgWR Wsks7cH2o=; b=GQaXsHQvjO3p9CgqpL8Uf5e0fhfpoL5aFEMxdwYEUqIY3YwTed LNgWWO9zeET+1cftVXU9C0UK2GNZq05GIfxLkngi2BOzfyAefUZn0hzvQPsDW8iI hLJa45/yEq+WD9xS7MrLxSBB/QtBvrmGbs+EWlzI/6o5uDvn2mzhl44cg=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 15 Nov 2020 23:49:25 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 15 Nov 2020 23:49:23 +0100
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000464897.msg for <ipv6@ietf.org>; Sun, 15 Nov 2020 23:49:22 +0100
X-MDRemoteIP: 2001:470:1f09:495:d190:15c3:5a26:85ed
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Sun, 15 Nov 2020 23:49:22 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1588fc1146=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/16.43.20110804
Date: Sun, 15 Nov 2020 23:49:17 +0100
Subject: Re: Extending a /64
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: ipv6@ietf.org
Message-ID: <9FF81EA8-039A-44E2-BDFC-44DBF2BFEDD8@consulintel.es>
Thread-Topic: Extending a /64
References: <005ECBB3-088B-4363-BB53-8D4AD25CA3D2@employees.org> <b468124f-f85b-7e20-a354-c6b7eaba3447@mccallumwhyman.com> <5B4CE94D-F7B9-4211-8E1D-6715AF78340C@consulintel.es> <CABNhwV1+5gOOUG=6DsBTFNrEN9rWdeMexhypuJJ0O4mWiDELQQ@mail.gmail.com>
In-Reply-To: <CABNhwV1+5gOOUG=6DsBTFNrEN9rWdeMexhypuJJ0O4mWiDELQQ@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3688328957_2062580510"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7T8NC4EZR4osI3AzoIsuNCXw1QQ>
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: Sun, 15 Nov 2020 22:49:41 -0000
It depends on what you justify. In all the RIRs it is need based justification. The first think to understand is the difference between and ISP and end-user from the perspective of the RIRs. An ISP get an allocation so they can “assign” to customers. While end-users (corporations, universities, etc.), only get an assignment and can’t sub-assign to others (others in the sense of different organizations, even not sub-organizations). Typically, every site, for end-users will get from the RIR an assignment for a /48. A corporation with multiple sites, will get n*/48. Most of the RIRs start for ISPs, allocating /32. In the case of RIPE NCC, ISPs, can request an allocation of /29 instead of /32 for each LIR account (a single company can justify multiple LIR accounts). In all the RIRs, beside what I’ve summarized above, if you justify a need for more, you get it, no trouble. For example, if an ISP has 5.000.000 subscribers, and they make an addressing plan for /48 to each subscriber, they will get the prefix that can hold all those. In this case it will be probably a /25. I think there are some cases in EU, of bit ISPs with /19, or /20. There are several European governments that got also /24-/26 or so. The /48 is not per-human, it is per site. I did “per-human” in the rfc6177-bis slides, just to set an example of how big is the IPv6 space. There is a global policy for covering the release of /12 for each RIR that is close to exhaust their existing pools. That’s the reason, if I recall correctly, why RIPE NCC and ARIN already got a 2nd /12. So, this is not a problem at all, never mind an ISP needs a /12, /16 or whatever, if it is justified according to the policies (which is really easy). If an ISP needs a /11 and it is justified, I believe the RIR will get 2 extra /12 from IANA for covering that. If we want to change that (the way IANA provides the /12 to the ISPs), it needs a global policy, which means the same “text” need to be approved by the community of all the 5 RIRs. Originally, instead of /12, it was /23, and we changed that once the IPv6 commercial deployment started. Both IANA and the RIRs do sparce allocation, so if you got a /12 and need another one, actually you just get one extra bit, not a new prefix. For an ISP that got a /28 (for example), instead of a new prefix (if it justifies the need to grow the actual prefix), will get one extra bit, so it will be the same prefix, but /27. Regards, Jordi @jordipalet El 15/11/20 22:44, "Gyan Mishra" <hayabusagsm@gmail.com> escribió: Hi Jordi >From the end allocation model standpoint as standard procedure is for ISPs to go to RIR for their allocations and not directly to IANA. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml Typically the ISP generic allocation size has been a /32 but that is pretty small as it yields only 64k /48s. What is the typical allocation size to ISPs? I was trying to find? My guess is for most RIRs the standard is /24 per ISP and /32 for large enterprises. A /24 would yield 11.7 million /48s which is way low for ISPs for /48 per human The allocation for ISPs has to be at least /22 or /20 for really large ISPs to do a /48 per human. https://www.ripe.net/publications/docs/ripe-699 What are the chances that in the future additional blocks will free up by IANA to RIR so that the large ISPs can be more like a /16 which would give 4.2 billon /48s per ISP. The caveat is if you go down to /16 that only gives 13 bits in total down to /3 split up between the RIRs so not feasible now until IANA releases more blocks. I think what would make sense is a /3 per RIR and then each ISP could get a /16 in theory but even then 13 bits is pretty small as it definitely won’t cover all the ISPs in a region. I am trying to wrap up “race to bottom” slide for v6ops presentation this week. Thanks Gyan On Sun, Nov 8, 2020 at 2:23 PM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote: IANA can't directly allocate to ISPs or end-users, unless the IETF documents a special case, which I don't think is required because it can perfectly follow the existing policies in the relevant RIR. You need to follow the process with the relevant RIR, according to their existing policies. I understand that in the case of ICAO, it will be ARIN. Even allocating a /48 to each possible human in the earth, there is not any problem. See slide 6 at: https://www.ietf.org/proceedings/103/slides/slides-103-v6ops-ipv6-address-assignment-to-end-sites-00 Regards, Jordi @jordipalet El 8/11/20 14:01, "ipv6 en nombre de Tony Whyman" <ipv6-bounces@ietf.org en nombre de tony.whyman@mccallumwhyman.com> escribió: The problem of the /64 limit came up in ICAO working groups earlier this year when developing a global addressing plan for the ATN/IPS and there would be strong support here for allowing subnet prefixes to go beyond the /64 boundary. Our problem is that we wanted to define an addressing plan that uses 39 bits to identify each aircraft, allows for a minimum of 4 more bits for subnetting and works within the existing standards. I'll give some background below for those interested in why 39 bits, but the problem is that if you are going to allocate a /64 (deriving from a /60 MNP) to each subnet on an aircraft then you need a /21 as your initial allocation - and this is before you start thinking about other ATN/IPS users such as drones. In order to avoid a potential problem getting a sufficient address allocation, we did look at extending into the "other 64 bits" of an IPv6 address for subnet IDs, which was looking very "unused". After all, you can only cram in a handful of systems into the avionics bay of even the biggest aircraft and, if you extend the addressing scheme into the back cabin, passengers can only bring on so many mobile phones, tablets and laptops in their hand luggage. 64 bits is an overkill for the host identifier and, if only we could have allocated (e.g.) a /96 for each aircraft subnet, then the problem would just go away. In the end, we concluded that we could not bend the existing standards to do this and did not have the desire to push for change. Hence, we are in the process of asking IANA for a /16 for the global civil aviation community. Hopefully we will get this. However, an argument is expected given that the current policies push back against such a large allocation and demand a utilisation efficiency that we will never achieve. However, if we don't get a /16 and the standards stay as they are, then a private address space and NAT at the boundaries may be the only answer - not really what anyone wants. I would certainly support raising the existing limit. A hard limit of a /96 would seem to be a good idea to stop ISPs going too far. It's probably also worth noting that perhaps one day every home on the planet may require an IPv6 Prefix. That is perhaps over a billion given the world's population. With densely packed address allocation that still requires 30 or so bits. Once you take into account any kind of geographical sub-allocation then you will need a lot more. A /96 would seem to be much easier to live with than a /64. Tony Whyman, MWA Background ----------------- For operational reasons, the ATN/IPS address allocation should allow for a common prefix for all aircraft operated by the same airline. Network diagnostics and firewall rules are often cited in support of such a requirement. It is also highly desirable that there should be a common prefix for all airline IPv6 Address Prefixes. Again this is to support simple firewall rules. Resisting DoS attacks is extremely important in our environment and these include firewall rules that prevent packets from external sources being sent to aircraft unless authorised, if only to minimise the risk of overloading limited capacity wireless subnetworks. If every airline and ATC Centre has a different address prefix then managing these rules will be an almost impossible task if they all have unrelated prefixes. A common ICAO prefix is thus highly desirable as are common prefixes for each category of address space user. It is believed that 15 bits is the minimum necessary to sub-allocate a prefix to each airline registered with ICAO. This leverages an existing registration scheme and allows for a reasonable degree of growth. There are also very good reasons for using the existing ICAO 24-bit aircraft identifier as part of an aircraft''s /60 MNP i.e. to sub-allocate each airline's address space to each of their aircraft. For very good safety reasons, ATC Centre Flight Data Processors need to correlate datalink messages (callsigns and 24-bit), surveillance reports (radar and ADS-B - which also use the 24-bit scheme), voice messages (using callsigns) and Flight Plans. Basically, you don't want to introduce yet another identifier into the mix and the use of overlapping schemes improves confidence in the overall result. There is also the small matter of backwards compatibility with the existing ATN/OSI CLNP addressing scheme. This also uses an airline identifier/24-bit approach to address allocation and if we keep to the same address semantics then it becomes feasible to introduce the ATN/IPS with minimum impact on the high certification environment of the Flight Data Processor. Any alternative will cost a lot more and put back deployment for several years. So, we really are boxed in and 39 bits + 4 bits for aircraft subnets is the minimum needed for assignment of a /64 to each aircraft subnet. Hence, the need for at least a /21, which ends up as a request for a /16 when you add in other users and a desire for nibble boundaries. On 08/11/2020 10:25, otroan@employees.org wrote: > Starting a new thread. > > A problem described in variable-slaac is: > > "It should be possible to extend an end-user network that is only assigned a /64" > > I believe that is a problem worth looking at. > This problem is not only restricted to the mobile access case, think connecting a host with VMs to a link. > > The address delegation to a site problem is intertwined with the autonomous networking problem of the site itself. The IETF solution is DHCPv6 PD + HNCP. The expectation of addressing of a network is that the addresses are long-lived. > > There are many potentional solutions: > > a1) ask the network operator for more address space. > a2) change provider > a3) introduce government regulation > b1) steal the uplink /64 (64share) > b2) steal multiple /64s from uplink > c) overlay. use e.g. LISP to tunnel across the access ISP to connect to an ISP that support multi-homing and larger address space. > d) MultiLink Subnet Routing. I.e. let a single /64 span multiple links. draft-thubert-6man-ipv6-over-wireless, draft-ietf-ipv6-multilink-subnets > e) NAT > f) P2P Ethernet. Hosts are not on the same physical link, so let's stop pretending they are. A consequence of that is that links don't need subnets. Only assign addresses to hosts. draft-troan-6man-p2p-ethernet-00 > g) extend the /64 bit boundary. HNCP implementations do /80s I think (forces DHCP for address assignment) > > > Requirements: > R-1: Permissionless. Not require an action on the network operator > R-2: Arbitrary topology > R-3: Long-lived address assignments > R-4: Support bad operational practice: flash renumbering / ephemeral addressing > > > Is there interest to work on this problem? > If so, suggestions for next steps? > > Best regards, > Ole (without any particular hat on) > -------------------------------------------------------------------- > 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 -------------------------------------------------------------------- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
- 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