Re: 64bit IIDs are both recommended and required

[Mark Smith <[e-mail]>]

On 17 July 2017 at 15:14, Alexandre Petrescu
<[e-mail]> wrote:
> Le 15/07/2017 à 19:54, David Farmer a écrit :
> [...]
>>
>> Also a problem statement was asked for, and I think that is it, "a simple
>> statement requiring or recommending 64 bit IIDs doesn't accurately reflect
>> the true nature of the IPv6 architecture."
>
>
> If a problem statement is formulated, it is worth adding the following.
>
> The 64bit IIDs make for a problem of 'growth at the edges'.  Such a
> problem has to do with use-cases like when using a smartphone to
> 'tether'.  Connect the smartphone on 4G and give others Internet on
> WiFi, such as to 'grow' the network.  Similar use-cases are: a WiFi
> Access Point, an IoT Gateway, an automobile On-Board Router, a Road-Side
> Unit, an satcom-WiFi router in an airplane.
>
> Such a device is present at the edge of the Internet.  It obtains a /64
> from a provider (a cellular or an ADSL provider).  It then has to make
> up other /64s to give others.  It cant.
>

It can't because the cellular or ADSL provider doesn't want the device
to be able to. If they did, then they should have no issue with
providing multiple and enough /64s to do so, in particular given how
cheap /64s are.

The IETF facilitating further subdivision of a /64 in this case is
purposely facilitating overriding a network operator's policy. It may
be miserly or irrational choice, however it isn't an accidental one.

That shouldn't be necessary, RFC6177 specifically says that if a site
needs more than one subnet, then the site should be given multiple
/64s. That's the IETF solution to this problem. Perhaps about the only
issue with RFC6177 is that it is written as though a site is always
physical location like a home, rather than being a bit more general
and saying that a "site' is the edge of a downstream multi-subnet
domain (e.g., the cellular phone case).

There are of course possible work arounds, e.g., race to the bottom
subdividing, NAPT etc. Developing those options is not a good spend of
IETF time because there's a much cheaper and existing option - give
out enough /64s to facilitate multiple downstream subnets.



> That's the problem of growth at the edges.
>

A single /64 is purposely preventing growth at the edges.

> This problem is made worse by current technical difficulties in using
> DHCPv6 and DHCPv6-PD, like lack of interoperability.
>
> This problem has a counterpart problem that is a 'race to the bottom'.
>
> (a few people's ideas are in what I write above)
>
> [...]
>>
>> I think the following more accurately conveys the true nature of the IPv6
>> architecture in regards to IIDs;
>>
>> Several components of IPv6 architecturally require Unicast Addresses with
>> fixed length Interface Identifiers that are 64 bits long, except
>> addresses that start with the binary value 000, primary of these is
>> Stateless Address Autoconfiguration (SLAAC) [RFC4862], other examples
>> are discussed in [RFC7421]. Whereas other components of IPv6 are
>> explicitly designed operate with Interface Identifiers of any length,
>> Neighbor Discovery (ND) [RFC4861], DHCPv6 [RFC3315] and unicast
>> routing [RFC7608] are examples of these. Therefore, the use of 64 bit
>> Interface Identifiers are recommended to ensure all components of
>> IPv6 operate as designed. However, there are several situations where
>> Interface Identifiers of other lengths can safely be used, these
>> include loopback interfaces, point-to-point router links [RFC6164],
>> and links where all nodes are configured manually or with DHCPv6.
>> Although, links with any nodes that are configured with SLAAC require
>> 64 bit Interface Identifiers.
>>
>> What do others think?
>
>
> The paragraph above makes sense in itself.  But is it a problem
> statement, or is it a solution to add in the rfcbis?
>
> Alex
>
>>
>> -- =============================================== David Farmer
>> Email:[e-mail] <mailto:[e-mail]> Networking &
>> Telecommunication Services Office of Information Technology University of
>> Minnesota 2218 University Ave SE        Phone: [phone] Minneapolis, MN
>> 55414-3029   Cell: 612-812-9952
>> ===============================================
>>
>>
>> --------------------------------------------------------------------
>>  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
> --------------------------------------------------------------------