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

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jul 2017 15:18:16 +1000

On 13 July 2017 at 12:05, Brian E Carpenter <[email-masked]> wrote:
> On 13/07/2017 01:53, Lorenzo Colitti wrote:
>> On Wed, Jul 12, 2017 at 11:39 AM, Brian E Carpenter <
>> [email-masked]> wrote:
>>

<snip>

> Nick Hilliard just did:
>
>>> 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.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 13 Jul 2017 16:47:58 +0100

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 13 Jul 2017 17:50:13 +0200

A divergence, but just to mention it...

Le 13/07/2017 à 07:18, Mark Smith a écrit :
[...]
> 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.

For example RFC8064 says:
> 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

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jul 2017 08:19:42 +1000

On 14 July 2017 at 01:50, Alexandre Petrescu
<[email-masked]> wrote:
>> 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.
>
>
> 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).

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jul 2017 11:48:55 +1200

Mark,

> 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