Subject: 64bit IIDs are both recommended and required

From: David Farmer <[email-masked]>
Date: Sat, 15 Jul 2017 12:54:20 -0500

Listening to the discussion for the last couple weeks, it seems apparent
that a simple statement requiring or recommending 64 bit IIDs doesn't
accurately reflect the true nature of the IPv6 architecture.  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."

A statement simply requiring 64 bit IIDs, as in RFC4291, ignores the
following;

- /128 prefixes are frequently assigned to loopback addresses for routing
protocols.
- /127 or /126  prefixes are frequently assigned to point-to-point router
links.
- Further it is common to assign these /128, /127, and /126 prefixes out of
a common /64 prefix.

- ND and unicast routing are explicitly designed to work with IIDs of any
length
- DHCPv6 IA_NA and IA_TA provide no routing information, the on-link prefix
come from PIOs in RAs, and can be any length.
- Most IPv6 implementations allow the manual configuration of prefixes of
any length

On the other hand, a statement simply recommending 64 bit IIDs doesn't
accurately reflect the following either;

- The Link-Local IID length has to be known, and there are no easy
mechanisms to discover it, therefore it is defined to be 64 bits for all
current link types.
- SLAAC uses the Link-Local IID to create other Unicast Address types and
requires 64 bit IIDs for Unicast Address assignment and on-link
determination for proper operation.
- As currently defined, many other parts of IPv6 assume Unicast Address
assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc...

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?

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Simon Hobson <[email-masked]>
Date: Sat, 15 Jul 2017 19:49:46 +0100

David Farmer <[email-masked]> wrote:

> On the other hand, a statement simply recommending 64 bit IIDs doesn't accurately reflect the following either;
> 
> - The Link-Local IID length has to be known, and there are no easy mechanisms to discover it, therefore it is defined to be 64 bits for all current link types.

That's OK - but really LL addresses are a special case.

> - SLAAC uses the Link-Local IID to create other Unicast Address types and requires 64 bit IIDs for Unicast Address assignment and on-link determination for proper operation.

Is that correct ? I was under the impression that SLAAC can use any prefix length advertised in an RA. The use of hardware address derived addresses is deprecated - and therefore any fixed 64 bit requirement should also be deprecated ?
The only remaining argument I've seen for keeping the 64 bit split is for privacy/security by making the available address space "very large" - but that in itself doesn't need a "fixed" 64 bit.

> - As currently defined, many other parts of IPv6 assume Unicast Address assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc...

"Assume" or "require" ?

As I've said earlier, I think the safest option is the require (as in *MUST*) implementations to work with arbitrary prefix lengths. If an implementation can handle an arbitrary split, then it can handle a 64/64 split - if you allow fixed assumptions then it's storing up *potential* problems later on. Who knows what someone might come up with in the next few decades !

---

From: David Farmer <[email-masked]>
Date: Sat, 15 Jul 2017 14:32:33 -0500

On Sat, Jul 15, 2017 at 1:49 PM, Simon Hobson <[email-masked]>
wrote:

> > - SLAAC uses the Link-Local IID to create other Unicast Address types
> and requires 64 bit IIDs for Unicast Address assignment and on-link
> Is that correct ? I was under the impression that SLAAC can use any prefix
> length advertised in an RA. The use of hardware address derived addresses
> is deprecated - and therefore any fixed 64 bit requirement should also be
> deprecated ?
> The only remaining argument I've seen for keeping the 64 bit split is for
> privacy/security by making the available address space "very large" - but
> that in itself doesn't need a "fixed" 64 bit.
>

RFC4862 says:
      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.  An implementation MAY wish to log a system management
      error in this case.  The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291].

And RFC4291 clearly says IIDs are 64 bits long, and I'm not aware of any
link type document that specifies something different that 64 bits.

> assignments based on 64 bit IIDs, Embeded RP Multicast, Mobile IP, etc...

Doesn't matter, things will break, can you redefine some of theses, sure,
but not by simply changing a few paragraphs in RFC4291bis.

> As I've said earlier, I think the safest option is the require (as in
> *MUST*) implementations to work with arbitrary prefix lengths. If an
> implementation can handle an arbitrary split, then it can handle a 64/64
> split - if you allow fixed assumptions then it's storing up *potential*
> problems later on. Who knows what someone might come up with in the next
> few decades !
>

At one level, I agree with you. But that is not what was done, some parts
of IPv6 require variable prefixes and IIDs, where other parts require fixed
length 64 bit prefixes and IIDs, that is the facts on the ground, yes it's
a little schizophrenic, but it is the way it is. You can't change that
without changing all the parts of IPv6 that require fixed length 64 bit
IIDs first, and changing a couple paragraphs in RFC4291bis can't do that.
Further, I don't see consensus to go modify all of the other part of IPv6
first even if that is what I would prefer to do.

However, accurately stating that some parts of IPv6 require variable length
prefixes and IID and other parts require fixed length 64 bit prefixes and
IIDs is something that can be done in RFC4291bis. In fact I think it has to
be done to accurately describe IPv6 and move the IPv6 Address Architecture
to Internet Standard.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: David Farmer <[email-masked]>
Date: Sat, 15 Jul 2017 14:51:12 -0500

On Sat, Jul 15, 2017 at 12:54 PM, David Farmer <[email-masked]> wrote:

> - Further it is common to assign these /128, /127, and /126 prefixes out
> of a common /64 prefix.
>
> - DHCPv6 IA_NA and IA_TA provide no routing information, the on-link
> prefix come from PIOs in RAs, and can be any length.
A minor tweak;

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 intended to be configured manually
or with DHCPv6. Although, links with any nodes that are intended to be
configured
with SLAAC require 64 bit Interface Identifiers.

What do others think?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Jul 2017 10:45:30 +1200

On 16/07/2017 07:51, David Farmer wrote:
...
> with SLAAC require 64 bit Interface Identifiers.

This is valid commentary, but I don't want to lose the clarity of the latest
draft:

   Interface Identifiers are 64 bit long except if the first three bits
   of the address are 000, or when the addresses are manually
   configured, or by exceptions defined in standards track documents.

At this point I'm completely past caring whether it says "are" or
"must" or "recommended", as long as all three exceptions are included.

     Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Jul 2017 23:58:27 +0100

> "must" or "recommended", as long as all three exceptions are included.

it would be appropriate for the exception list to include any address
assignment mechanism where addresses are assigned by the network (as
opposed to addresses which are self-selected by the host).

Nick

---

From: David Farmer <[email-masked]>
Date: Sun, 16 Jul 2017 18:13:09 -0500

Sent from my iPhone

>> On Jul 16, 2017, at 17:45, Brian E Carpenter <[email-masked]> wrote:
>> 

The current text doesn't explicitly cover DHCPv6, given the level of debate back and forth on this, the status of DHCPv6 in this should be abundantly clear.  Personally, I believe it has any length IIDs just like manual config. But, even if I'm in the rough on this, I'll accept that, as long as it is explicitly clear either way. 

When we're done with this there can't be open questions like the status of DHCPv6.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 07:14:59 +0200

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.

That's the problem of 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:[email-masked] <mailto:[email-masked]> Networking & 
> Telecommunication Services Office of Information Technology 
> University of Minnesota 2218 University Ave SE        Phone: 
> 612-626-0815 Minneapolis, MN 55414-3029   Cell: 612-812-9952 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Jul 2017 15:48:41 +1000

On 17 July 2017 at 15:14, Alexandre Petrescu
<[email-masked]> wrote:
>> Also a problem statement was asked for, and I think that is it, "a simple

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.

>> fixed length Interface Identifiers that are 64 bits long, except
>> Telecommunication Services Office of Information Technology University of
>> Minnesota 2218 University Ave SE        Phone: 612-626-0815 Minneapolis, MN
>> 55414-3029   Cell: 612-812-9952
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 13:54:10 +0200

> providing multiple and enough /64s to do so, in particular given how

I can agree to that, but it does not make it less of a Problem.

Further, I heard today other problems during the meeting:
- network management: ANIMA work may need longer-than-64bit prefix
   lenghts
- Android emulator may not allow for NAT

Alex

[...]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jul 2017 08:35:30 +1200

On 17/07/2017 23:54, Alexandre Petrescu wrote:
...
> - network management: ANIMA work may need longer-than-64bit prefix

That's not a real problem. Anima doesn't need longer prefixes for
address allocation purposes - it really allocates /128s directly
to nodes in the autonomic control plane. It does need to use longer
prefixes for routing within the autonomic control plane, consistent
with BCP198, but that isn't a problem at all. (This has become clear
since yesterday's meeting.)

> - Android emulator may not allow for NAT

You'll have to explain to me why I care about that.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jul 2017 22:59:14 +0200

> You'll have to explain to me why I care about that.

The person who has to explain that is the person who expressed that view 
at the microphone.  Lorenzo?

Alex

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jul 2017 15:53:45 +1000

On 17 July 2017 at 21:54, Alexandre Petrescu
<[email-masked]> wrote:
>>>> simple

I think it makes it less of a problem.

We need to assume and cater to the common and sensible cases. If we
start trying to accommodate or work around either unnecessary and
irrational cases or cases with specifically and consciously chosen
constraints, we end up rewarding those exceptions with our time and
penalising the sensible and more accommodating.

If a network has chosen not to give out more than one /64, despite
them having a minimum of 4 294 967 296 x /64s i.e., a /32's worth from
an RIR, and despite the advice in RFC6177, why should we spend
valuable time overcoming that?

Better to advise the end-user to find a better network where their
provider actually satisfies their needs (or use an IPv6 in IPv6 tunnel
provided by somebody else to get more than a /64). Better to advise
the provider to follow the advice in RFC6177 and better facilitate
their customers' needs.

It's a slippery slope that eventually leads to a /128 and NAPT. If you
want to accommodate > /64, then the easiest and quickest way to do
that is to assume the worst and only case of a /128 and work on that.
You'll never be able to guarantee more than that from somebody who
wants to go past /64, so there is always a risk that what you're given
won't be enough to give each device its own address.

> - Android emulator may not allow for NAT

Once the boundary becomes arbitrary, Android and other similar devices
will have only two choices:

- to include NAPT code to work around the case of not being given
enough addresses to address each device individually

- refuse to connect to a network that doesn't give out enough
addresses to address each device individually

Regards,
Mark.