Re: Extending a /64

[JORDI PALET MARTINEZ <[e-mail]>]

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" <[e-mail] en nombre de [e-mail]> 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, [e-mail] 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
    > [e-mail]
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [e-mail]
    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.