Re: Extending a /64

[Gyan Mishra <[e-mail]>]

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=
[e-mail]> 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" <[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.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD