Subject: Re: Prefix delegation based on standard IPv6 ND messaging

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 1 Oct 2018 11:03:53 +0200

Le 26/09/2018 à 21:54, Templin (US), Fred L a écrit :
> Hi, we have come up with a "new" way of coordinating prefix delegation without
> DHCPv6 messaging and without requiring any new IPv6 ND options nor modifications
> to existing options or messages. The method applies only to environments where a
> node has been administratively assigned an IPv6 prefix by the administrative authority
> for the network. The prefix length must also be the same (e.g., /56, /60, etc.) for all
> nodes that connect to the network.
> 
> Given the above requirements, the node can insert its network prefix into the
> IPv6 source address of a Router Solicitation (RS) using the AERO address format.
> In this format, if the node holds the prefix 2001:db8:1:2::/64 then the corresponding
> AERO address is fe80::2001:db8:1:2. The node then sends the RS to either the
> all-routers multicast address or to the unicast address of a specific router.
> 
> When the router(s) receives the RS message, it first determines the node's
> authority to use its claimed prefix. The router(s) then injects the prefix
> 2001:db8:1:2/64 into the routing system and returns an RA message to
> the node.

Looks interesting to me.

Delegating prefixes becomes a matter of convention between pairs of 
nodes.  It does not modify packet formats.  It takes advantage of the 
bit space available in huge 128bit IPv6 addresses.

It may involve a privacy risk: the Interface Identifier signifies a 
(presumably fixed) prefix valid in a network, rather than an obscure 
number generated randomly.

It could be solved by squeezing the 2001:db8:1:2::/64 into 54 bits, and 
IANA allocating new link-local space allowing these 54 bits to be non-zero.

Such that the src address be: fe80:2001:db8:sqzd:4545:1656:6515:1346
(remarq sqzd - squeezed, and obscure IID).

Alex

> 
> When the node receives the RA message, it uses the default router lifetime
> as the time before which it must perform an additional RS/RA message in
> order for the network to retain its routing state. Everything is coordinated
> by standard RS/RA messaging.
> 
> This system is documented in Section 4 of the following document:
> 
> https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
> 
> We are interested in receiving your comments.
> 
> Fred
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Oct 2018 14:20:24 +0000

HI Fernando,

Thanks for the questions, and see below:

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> Sent: Friday, September 28, 2018 4:50 PM
> To: Templin (US), Fred L <[email-masked]>; 6man <[email-masked]>
> Subject: Re: Prefix delegation based on standard IPv6 ND messaging
> 
> Fred,
> 
> I haven't read the doc, but I have read your summary explanation. Here
> are my questions/comments:
> 
> 1) How do you deal with collisions with hosts that just happen to
> generate the IID e.g. 2001:db8:1:2?

If it can be administratively assured (or assured through some form of
IPv6-over-foo specification) that there would be no nodes on the link
that would use any link-local address scheme other than the AERO
address, then there is assurance that there would be no duplication.
In environments where there is potential for duplication, DAD would
have to be used. But, I am looking at solutions for problem spaces
where duplication is not a concern.

> 2) How about gratituous RAs? If the local router does not send them,
> then that would seem a change to RFC4862.

This still works exactly the same if the routers send unsolicited RAs.

> 3) Why not use DHCPv6-PD? Let's duplicate all functionality on both
> protocols. Or if we don't, maybe just close dhcwg. (seriously). It seems
> we keep dhcwg going, while at the same time undermine any use of DHCPv6
> (I'm not saying *this* proposal is doing that).

I have tried very hard to position DHCPv6-PD as a universally applicable
solution, but there are just some environments where there is strong
opposition to its use. For example, DHCPv6-PD appeals to some enterprise
network managers, but in other environments like aviation it is seen as too
heavy-duty and a lighter-weight mechanism is desired.

In particular, DHCPv6 requires at least four messages (RS/RA/Solicit/Reply)
which can be seen as too many messages on some links. So, there is a great
deal of interest in keeping this to only a single message exchange (RS/RA).
Here is a taxonomy and specifications for alternatives:

https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

Thanks - Fred

> Thoughts?
> 
> Thanks,
> Fernando
> 
> 
> 
> 
> On 09/26/2018 04:54 PM, Templin (US), Fred L wrote:
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 1 Oct 2018 16:25:20 +0200

Fred,

> https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

Do you have more justification why +2 messages is a problem?

Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Oct 2018 14:26:13 +0000

Hi Alex,

I can't squeeze a 64-bit prefix into 54 bits, unfortunately. But, what might be
an attractive use of your 54 zero bits in conjunction with my proposal would
be to reserve 8 bits out of the 54 to encode a prefix length (e.g., 56, 60, 64,
etc.). Still, I don't think most implementations would know how to deal with
non zero values in those bits.

Thanks - Fred 

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Monday, October 01, 2018 2:04 AM
> To: [email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Oct 2018 14:45:41 +0000

HI Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Monday, October 01, 2018 7:25 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; 6man WG <[email-masked]>

Sure. As one example, on aeronautical data links bandwidths are typically
on the order of 1Mbps or less and so reducing the number of messages
used for autoconfiguration is critical. As a second example, on many wireless
data links there is a desire to reduce the number of multicast messages to
a minimum to avoid disturbing other nodes on the link with irrelevant
multicast traffic.

Some people in aviation industry standards bodies outside of the IETF
have also gotten the idea that DHCPv6 is "too much complexity" for
use on-board airplanes. They seem to be more satisfied by simple
RS/RA messaging, and let the network worry about the state
management needed to track prefix delegation state. So it seems
that what would satisfy them would be RS/RA on the front end
between the airplane and ground network with something like
DHCPv6 on the back end to manage prefix delegation state. But,
there would be no DHCPv6-specific messages over the air.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 1 Oct 2018 17:48:48 +0200

Fred,

> a minimum to avoid disturbing other nodes on the link with irrelevant

1Mbps is not in a historic sense a low bandwith link.
And what matters there isn’t the number of messages, but the number of bytes you send.

With regards to the multicast problem, there are many solutions to that.

> there would be no DHCPv6-specific messages over the air.

DHCP can of course be implemented “in the network”.

What _does_ add complexity is to have two or more solutions to the exact same problem.

For that reason I think this is not a good idea.

Best regards,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Oct 2018 16:04:34 +0000

Hi Ole,

> Sent: Monday, October 01, 2018 8:49 AM

I said 1Mbps "or less". Some links like VHF are as little as 32Kbps.

> With regards to the multicast problem, there are many solutions to that.

A L2 multicast is going to wake up any nodes on the link that hear it
and disturb them from their sleep mode, which is undesirable.

> DHCP can of course be implemented “in the network”.

Something like DHCPv6 as the back end in the network is going to be
needed, yes. But, the front end (the piece the client sees) can be
simple RS/RA which is a big savings in terms of network bandwidth.

> For that reason I think this is not a good idea.

Whether you like it or not, the aviation community does not want DHCPv6
on board the airplane. RS/RA is the only mechanism they want to see there.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 1 Oct 2018 19:43:50 +0200

Fred,

> I said 1Mbps "or less". Some links like VHF are as little as 32Kbps.

As long as you are sending more or less the same number of bytes, that doesn’t really matter much.
Unless you are going down some of these adaption layers developed in 6lo?

> and disturb them from their sleep mode, which is undesirable.

There are already many mechanisms developed to deal with that.

> simple RS/RA which is a big savings in terms of network bandwidth.

Can you show us how big, in terms of the total amount of control traffic?

> on board the airplane. RS/RA is the only mechanism they want to see there.

“Want” isn’t a very convincing argument in a consensus based group made up of volunteers.

If there is any critique of IPv6, it is that the configuration mechanisms are too complex. That is largely a result of there being two competing mechanisms, and redundant ways of doing things.
I think you would also agree then, that there must be a high bar before we should add more redundant protocols.

Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Oct 2018 18:14:18 +0000

Hi Ole,

> Sent: Monday, October 01, 2018 10:44 AM

If we can get by with sending just a simple RS/RA with no extra ND options
and with no DHCPv6  Solicit/Reply then there are quite a few less bytes.

> There are already many mechanisms developed to deal with that.

But, the best mechanism is to have fewer messages in the first place.

> Can you show us how big, in terms of the total amount of control traffic?

DHCPv6 messages are big and RS/RA messages are not nearly so big. And, that
is just for a single client. If there are many clients (e.g., lots of airplanes sharing
the same RF broadcast domain) then having, e.g., a 50% or more savings on the
number of bytes used for autoconfiguration purposes becomes significant.

> If there is any critique of IPv6, it is that the configuration mechanisms are too complex. That is largely a result of there being two
> competing mechanisms, and redundant ways of doing things.

That is why I am proposing "A Unified Stateful/Stateless Autoconfiguration Service
for IPv6":

It combines the two autoconfiguration services into a single service while leveraging
the best aspects of both. It can be tailored to the network characteristics of each use
case to do only that which is needed as opposed to having to use the whole kitchen
sink for all cases. This would seem to address your desire for a single, unified service
wouldn't it?

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 1 Oct 2018 20:53:00 +0200

Hi Fred,

> sink for all cases. This would seem to address your desire for a single, unified service

https://xkcd.com/927/

Presumably on these links there is no “superfluous” traffic? Address resolution? MDNS? People browsing web pages full of ads?
Are you really sure you are trying to optimise where optimisation is worth it?

Best regards,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Oct 2018 19:39:44 +0000

Hi Ole,

> Sent: Monday, October 01, 2018 11:53 AM

That is funny, but is sort of the opposite situation of what I am proposing. We
already have IPv6 ND vs. DHCPv6. What I am proposing is combining the union
of IPv6 ND and DHCPv6 - not inventing some new XYZ protocol.

> Are you really sure you are trying to optimise where optimisation is worth it?

If you are talking about the aviation use case, most of what is sent on these low-end links
is infrequent but safety-critical short text messages. Certainly no address resolution, MDNS,
web browsing, etc. So, the optimization is worth it but this is about more than optimization.
It is about a unification of the best aspects of both services.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Tue, 2 Oct 2018 10:32:31 -0400

Hi Fred,
     Would be curious about views as to how this approach differs
significantly from previous attempts to create a non-DHCP-based prefix
delegation protocol.

https://tools.ietf.org/html/draft-kaiser-nd-pd-01
https://tools.ietf.org/html/draft-bykim-ipv6-hpd-01
https://tools.ietf.org/html/draft-haberman-ipngwg-auto-prefix-02

None of those are mentioned in your draft.

Regards,
Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 2 Oct 2018 15:10:56 +0000

Hi Brian,

Those drafts go back a few years, and I did not see them. My draft proposes
four different possibilities for IPv6 ND-based prefix delegation (see below).
Please let me know your thoughts.

Fred
[email-masked]

---

2.  DHCPv6 Options in IPv6 ND Messages

- in this section, the design of a new NDP option is proposed, where the option is
  identical to a DHCPv6 message. The DHCPv6 message option is included in RS
  messages to solicit a prefix and in RA messages to delegate a prefix. All other
  DHCPv6 messages (Renew/Rebind/Release/etc.) are supported through their
  inclusion in RS/RA messages. I have not seen other documents suggest including
  a DHCPv6 message within an IPv6 ND message.

3.  PIO Options in RS Messages

- In this section, it is proposed to include a PIO option with the "X" bit set within an
  RS message to solicit a prefix delegation from a router acting as specified in
  'draft-pioxfolks-6man-pio-exclusive-bit'. I have not seen other documents
  suggest including a PIO option with the X bit set in RS messages.

4.  Embedded Prefix Assertion

- In this section, it proposes to include an IPv6 prefix embedded within the interface
   identifier within the link-local source address of an RS message. The delegating
   router examines the link-local source address to determine the IPv6 prefix, and
   injects the prefix into the routing system. Neither the RS nor the RA carry any
   options pertaining to the prefix delegation.

5.  Out-of-Band Network Login Messaging

- This section suggests a Layer 2 (L2) message exchange between the requesting
   router and the network, which causes the delegating router to return an RA.
   No options pertaining to prefix delegation are included in the RA message.

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Tuesday, October 02, 2018 7:33 AM
> To: [email-masked]