64bit IIDs are both recommended and required

[David Farmer]

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?

[Simon Hobson]

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 !

[David Farmer]

Post by David Farmer

Post by David Farmer
On the other hand, a statement simply recommending 64 bit IIDs doesn't

accurately reflect the following either;

Post by David Farmer
- 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.

Post by David Farmer
- 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.

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.

Post by David Farmer

Post by David Farmer
- 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" ?

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

Post by David Farmer
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]

Post by David Farmer
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;

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?

[Brian E Carpenter]

On 16/07/2017 07:51, David Farmer wrote:
...

Post by David Farmer
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.

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

[Nick Hilliard]

Post by Brian E Carpenter
This is valid commentary, but I don't want to lose the clarity of the latest
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.

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

[David Farmer]

Sent from my iPhone

Post by Brian E Carpenter

Post by David Farmer
...
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.

This is valid commentary, but I don't want to lose the clarity of the latest
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

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.

[Alexandre Petrescu]

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
Telecommunication Services Office of Information Technology
612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
--------------------------------------------------------------------
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Mark Smith]

On 17 July 2017 at 15:14, Alexandre Petrescu

Post by Alexandre Petrescu
[...]

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.

Post by Alexandre Petrescu
That's the problem of growth at the edges.

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

Post by Alexandre Petrescu
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
Telecommunication Services Office of Information Technology University of
Minnesota 2218 University Ave SE Phone: [phone] Minneapolis, MN
55414-3029 Cell: 612-812-9952
===============================================
--------------------------------------------------------------------
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Alexandre Petrescu]

Post by Mark Smith
On 17 July 2017 at 15:14, Alexandre Petrescu

Post by Alexandre Petrescu
[...]

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.

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

[...]

[Brian E Carpenter]

On 17/07/2017 23:54, Alexandre Petrescu wrote:
...

Post by Alexandre Petrescu

Post by Mark Smith
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.

I can agree to that, but it does not make it less of a Problem.
- network management: ANIMA work may need longer-than-64bit prefix
lenghts

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.)

Post by Alexandre Petrescu
- Android emulator may not allow for NAT

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

Brian

Post by Alexandre Petrescu
Alex

[Alexandre Petrescu]

Post by Brian E Carpenter
...

Post by Alexandre Petrescu

Post by Mark Smith
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.

I can agree to that, but it does not make it less of a Problem.
- network management: ANIMA work may need longer-than-64bit prefix
lenghts

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.)

Post by Alexandre Petrescu
- Android emulator may not allow for NAT

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

Post by Brian E Carpenter
Brian

Post by Alexandre Petrescu
Alex

[Mark Smith]

On 17 July 2017 at 21:54, Alexandre Petrescu

Post by Alexandre Petrescu

Post by Mark Smith
On 17 July 2017 at 15:14, Alexandre Petrescu

Post by Alexandre Petrescu
[...]

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.

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

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.

Post by Alexandre Petrescu
- network management: ANIMA work may need longer-than-64bit prefix
lenghts
- 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.