Forgetting one of IPv6's themes (Re: IPv6 Routing & ND vs. Addressing, )

[Mark Smith]

On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <

<snip>

I would suggest that future protocols need to define what makes sense
for them, and mandating a constant in advance isn't necessary or even
appropriate.

Which is why I personally would be happy with the addressing
architecture either not mentioning 64 at all, or *recommending* 64,
or requiring 64 "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."
IMHO any of those three formulations would resolve Nick's problem
statement (given that there is also a citation of BCP198 in the
latest draft to clarify how routing works).

I think what Nick suggested is the total opposite of what should be
done and I think opposite to one of IPv6's major themes. Forming IIDs
should not be left to link-layer specific protocol specs.

I think one of the significant differences between IPv4 and IPv6 is
that a number of mechanisms have been made more generic and less
link-layer specific, or have been shifted from out of the link layer.

Specifically,

- ND is part of ICMP, rather than being a link-layer specific protocol
a ARP was.

- ND itself also tries to be as generic as possible, so that it can
operate over all link-types. Link unicast is a given, it expects a
link to emulate multicast if it isn't natively supported.

- IP and higher layer parameter configuration has been moved out of
PPP to upper layer and generic, non-link-layer specific protocols such
as RAs and DHCPv6.


We did have link-layer specific methods to generate IPv6 IIDs for
SLAAC, however RFC8064/RFC7217 has just deprecated all of them. IID
generation could be made link-layer agnostic because it was for
convenience rather than necessity.

Stateful DHCPv6 doesn't do link-layer specific or dependent addressing either.

Another way to consider what the IPv6 layer/protocol does is that it
abstracts away link-layer differences. As RFC6272 says in its overview
of the Internet Protocol Suite,

"The Internet layer provides a uniform network abstraction network
that hides the differences between various network technologies.
This is the layer that allows diverse networks such as Ethernet,
802.15.4, etc. to be combined into a uniform IP network. New network
technologies can be introduced into the IP Protocol Suite by defining
how IP is carried over those technologies, leaving the other layers
of the IPS and applications that use those protocol unchanged."


So, with IPv6 abstracting away the link-layer differences, for
consistency, IPv6 addresses are better to be abstract and decoupled
from underlying link-layer characteristics such as the link-layer
address characteristics and values.

Regards,
Mark.

[Nick Hilliard]

Mark,

I don't particularly want to get dragged down a rathole on ipv6
architecture philosophy, but regarding what you have written below, IPv6
was a product of its time and its design philosophy suffered from a
substantial degree of second system syndrome. A disconcertingly large
number of the core design principals have in retrospect proven to be of
high cost and of marginal practical value. In some cases, core features
have been problematic enough to recommend deprecation; in others, many
people are left wanting to deprecate design points but are unable to do so.

We are going to need to disagree on a wide range of issues, including
most of the things you mention below, none of which is particularly
relevant to this discussion except for the issue of generating IIDs,
about which:

1. /64 is a statement of policy rather than a constant intrinsic to the
protocol.

2. hard-coding semi-arbitrary constants in design specifications is a
poor idea at the best of times.

3. even then, IID generation in the cases you are talking about is
relevant for host-side address auto-selection protocols, not externally
assigned addressing.

4. even then, a hardcoded mask length is objectively unnecessary, as
implicitly acknowledged by the existence of the Prefix Length field in
the prefix information option in RA.

This entire discussion could be concluded with no practical fallout of
any form if /64 were specified for SLAAC and the constant were omitted
from the addressing architecture specification.

Nick

Post by Mark Smith

On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <

<snip>

I would suggest that future protocols need to define what makes sense
for them, and mandating a constant in advance isn't necessary or even
appropriate.

Which is why I personally would be happy with the addressing
architecture either not mentioning 64 at all, or *recommending* 64,
or requiring 64 "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."
IMHO any of those three formulations would resolve Nick's problem
statement (given that there is also a citation of BCP198 in the
latest draft to clarify how routing works).

I think what Nick suggested is the total opposite of what should be
done and I think opposite to one of IPv6's major themes. Forming IIDs
should not be left to link-layer specific protocol specs.
I think one of the significant differences between IPv4 and IPv6 is
that a number of mechanisms have been made more generic and less
link-layer specific, or have been shifted from out of the link layer.
Specifically,
- ND is part of ICMP, rather than being a link-layer specific protocol
a ARP was.
- ND itself also tries to be as generic as possible, so that it can
operate over all link-types. Link unicast is a given, it expects a
link to emulate multicast if it isn't natively supported.
- IP and higher layer parameter configuration has been moved out of
PPP to upper layer and generic, non-link-layer specific protocols such
as RAs and DHCPv6.
We did have link-layer specific methods to generate IPv6 IIDs for
SLAAC, however RFC8064/RFC7217 has just deprecated all of them. IID
generation could be made link-layer agnostic because it was for
convenience rather than necessity.
Stateful DHCPv6 doesn't do link-layer specific or dependent addressing either.
Another way to consider what the IPv6 layer/protocol does is that it
abstracts away link-layer differences. As RFC6272 says in its overview
of the Internet Protocol Suite,
"The Internet layer provides a uniform network abstraction network
that hides the differences between various network technologies.
This is the layer that allows diverse networks such as Ethernet,
802.15.4, etc. to be combined into a uniform IP network. New network
technologies can be introduced into the IP Protocol Suite by defining
how IP is carried over those technologies, leaving the other layers
of the IPS and applications that use those protocol unchanged."
So, with IPv6 abstracting away the link-layer differences, for
consistency, IPv6 addresses are better to be abstract and decoupled
from underlying link-layer characteristics such as the link-layer
address characteristics and values.

[Alexandre Petrescu]

A divergence, but just to mention it...

Le 13/07/2017 à 07:18, Mark Smith a écrit :
[...]

Post by Mark Smith
We did have link-layer specific methods to generate IPv6 IIDs for
SLAAC, however RFC8064/RFC7217 has just deprecated all of them. IID
generation could be made link-layer agnostic because it was for
convenience rather than necessity.

Well, that RFC pair is very ambitious. But it's hard to imagine
statements like "this RFC updates RFC1, 2... n" is very easy to do.

Post by Mark Smith
In particular, this document RECOMMENDS that nodes do not generate
stable IIDs with the schemes specified in ... RFC5072 ...

However: RFC5072 "ppp IPv6" is still in wide use, and the way it
generates a stable IID is by a ConfigReq/Ack negotiation, not by
extracting numbers from a local built-in hardcoded address.

Depending on how that PPP negotiation happens, on a case-by-case basis,
the IID offers some privacy when it is proposed by the terminal and
accepted by the network, or no privacy at all when it is proposed by the
network and accepted by the terminal.

So, it is not obvious how RFC8064 deprecates RFC5072.

Alex

[Mark Smith]

On 14 July 2017 at 01:50, Alexandre Petrescu

Post by Alexandre Petrescu
A divergence, but just to mention it...
[...]

We did have link-layer specific methods to generate IPv6 IIDs for SLAAC,
however RFC8064/RFC7217 has just deprecated all of them. IID generation
could be made link-layer agnostic because it was for convenience rather than
necessity.

Well, that RFC pair is very ambitious. But it's hard to imagine
statements like "this RFC updates RFC1, 2... n" is very easy to do.

In particular, this document RECOMMENDS that nodes do not generate
stable IIDs with the schemes specified in ... RFC5072 ...

However: RFC5072 "ppp IPv6" is still in wide use, and the way it generates a
stable IID is by a ConfigReq/Ack negotiation, not by extracting numbers from
a local built-in hardcoded address.

That's because PPP doesn't have a link layer addresses useful for IID
formation, so RFC5072 invents a method of generating them.

On a (true) point-to-point link there is no functional need for link
layer addresses as the only place anything can be sent to is to the
other end of the link.

PPP itself in RFC1661 doesn't specify link-layer addressing, and PPP
in HDLC-like Framing (which from memory is the framing we actually
use/used) sets the HDLC destination address to the "All-Stations
address" and says that individual addresses aren't assigned. On PPP
with HDLC-link framing, there is no frame source address and the
destination address is a link-layer broadcast address.

It's easy to think that Ethernet links directly between two devices
are "point-to-point" links. Physically they may be, however, the
ethernet protocol operating over the link is still a multi-access
protocol because it supports, assigns and uses individual link-layer
addresses. If somebody wanted to squeeze 12 more payload octets out of
an ethernet frame on a point-to-point physical link, they could switch
the interfaces on both ends into promiscuous mode and use the
addressing bytes for what ever they liked (a long time ago I thought
this could be where MPLS labels could be put, similar to how in Frame
Relay and ATM they reused the DLCI and PVC fields for MPLS label
information).

Post by Alexandre Petrescu
Depending on how that PPP negotiation happens, on a case-by-case basis, the
IID offers some privacy when it is proposed by the terminal and accepted by
the network, or no privacy at all when it is proposed by the network and
accepted by the terminal.

Yes. I've seen your concerns about the 3GPP spec and network forced
IIDs, and agree with them.

Reflecting on it, it is a perfect example of the security and privacy
risks of tightly coupling a link-layer addressing and IPv6 layer IID
generation. Functionally there is no issue.

Reusing identifiers from different layers can cause security and
privacy problems because the security and privacy scope at one layer
(e.g., within a single link-layer) can be different to the security
and privacy scope at the different layer where the identifier is
reused (e.g., across the Internet).

Even within a link there can be concerns, because an a multi-access
link there can be untrusted parties collecting security and privacy
sensitive identifier information. Identifiers really should change
across different links, so that the same untrusted party attached to
multiple links can't correlate the link-limited identifiers across the
links. Changing MAC addresses between different Wifi SSIDs is an
example of a mitigation of that risk.

Post by Alexandre Petrescu
So, it is not obvious how RFC8064 deprecates RFC5072.

RFC7217 will work on a link without link-layer addresses. It can use
link-layer addresses as one of the value types for the Net_Iface
parameter as an interface identifier, however there are 3 other types
suggested (Interface Index, Interface Name, Logical Network Service
Identity). Link-layer addresses is subtly recommended against, because
there is the risk that if the interface module is swapped, the
link-layer address can change, and that would stop the address being
stable across hardware replacement, one of the goals of RFC7217.

Regards,
Mark.

[Brian E Carpenter]

Mark,

Post by Mark Smith

On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <

<snip>

I would suggest that future protocols need to define what makes sense
for them, and mandating a constant in advance isn't necessary or even
appropriate.

Which is why I personally would be happy with the addressing
architecture either not mentioning 64 at all, or *recommending* 64,
or requiring 64 "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."
IMHO any of those three formulations would resolve Nick's problem
statement (given that there is also a citation of BCP198 in the
latest draft to clarify how routing works).

I think what Nick suggested is the total opposite of what should be
done and I think opposite to one of IPv6's major themes. Forming IIDs
should not be left to link-layer specific protocol specs.

Unfortunately it always has been that way. True, you can argue that it's
a mistaken holdover from Xerox PUP via Novell IPX. You can argue that
we wouldn't design it that way today. However, it's hard to squeeze
the toothpaste back in the tube.

RFC7217, which is applicable to all link types, is not bound exclusively
to 64. Neither is RFC8064, nor SLAAC. They all treat 64 as an externally
defined parameter.

Brian