Subject: Prefix delegation based on standard IPv6 ND messaging

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Sep 2018 19:54:16 +0000

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.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Sep 2018 20:50:03 -0300

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?

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

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

Thoughts?

Thanks,
Fernando

On 09/26/2018 04:54 PM, Templin (US), Fred L wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492