Subject: Fwd: New Version Notification for draft-naveen-slaac-prefix-management-00.txt

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 7 Nov 2018 06:29:52 +0530

Hello,

IPv6 StateLess Address AutoConfiguration (SLAAC) in its current form
doesn't offer following services like:

1. Soliciting a prefix of specific length.  The length could be of either
/64 bit prefix (which would generally be solicited by nodes) or non /64 bit
prefix (which would generally be solicited by either CPE or downstream
routers).
2. Releasing the prefixes that are no more used by the device.  This could
be equally important for the routers who assigned the prefix to make the
unused prefixes available for other nodes.

To achieve the above objectives, a ND based message protocol is introduced
in the below draft that does what a DHCPv6 node do; *without introducing
any new message types or new option types or flag types*.

Can you all share your thoughts on the draft?

Thanks & Regards,
Naveen

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Nov 7, 2018 at 6:14 AM
Subject: New Version Notification for
draft-naveen-slaac-prefix-management-00.txt
To: Naveen Kottapalli <[email-masked]>

A new version of I-D, draft-naveen-slaac-prefix-management-00.txt
has been successfully submitted by Naveen Kottapalli and posted to the
IETF repository.

Name:           draft-naveen-slaac-prefix-management
Revision:       00
Title:          IPv6 Stateless Prefix Management
Document date:  2018-11-06
Group:          Individual Submission
Pages:          15
URL:
https://www.ietf.org/internet-drafts/draft-naveen-slaac-prefix-management-00.txt
Status:
https://datatracker.ietf.org/doc/draft-naveen-slaac-prefix-management/
Htmlized:
https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-naveen-slaac-prefix-management

Abstract:
   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
   provision for the hosts to request for a specific IPv6 address and
   manage the same, whereas the StateLess Address AutoConfiguration
   (SLAAC) doesn't have such a provision.  Also, unavailability of
   DHCPv6 across all OS platforms has limited the IPv6 nodes to not use
   features like soliciting a prefix of desired length and lifetime,
   renewing, releasing / declining a prefix, etc.  This document
   proposes IPv6ND extensions for enabling SLAAC devices to solicit
   prefix information as a hint PIO in RS and other methods like
   renewing or releasing or declining a prefix without introducing any
   new ICMPv6 message or option types.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Nov 2018 09:38:45 +0700

> On Nov 7, 2018, at 7:59 AM, Naveen Kottapalli <[email-masked]> wrote:
> 
> Hello,
> 
> IPv6 StateLess Address AutoConfiguration (SLAAC) in its current form doesn't offer following services like:
> 
> 1. Soliciting a prefix of specific length.  The length could be of either /64 bit prefix (which would generally be solicited by nodes) or non /64 bit prefix (which would generally be solicited by either CPE or downstream routers).

SLAAC doesn't "solicit" anything. If you want a prefix with any specific attributes, you're in the territory of RFC 3633.

> 2. Releasing the prefixes that are no more used by the device.  This could be equally important for the routers who assigned the prefix to make the unused prefixes available for other nodes.

SLAAC doesn't do *anything* with prefixes.

> To achieve the above objectives, a ND based message protocol is introduced in the below draft that does what a DHCPv6 node do; without introducing any new message types or new option types or flag types.
> 

My first thought is that a 2001 draft is a bit long in the tooth. Was it really posted in June 2001?

The second is that "autoconfiguration" is a bit different than anything that one might solicit from or release to a network. For example, with addresses, routing is handled by the router that advertised the prefix in its RA (and maybe by other routers); when one solicits and starts to use a prefix, one needs to advertise it in routing, which means that one is going to need to implement and advertise some routing protocol.

Third - L2TP is a bit dated. Maybe that's the reason for the 2001 date on the draft. A 2013 article (https://www.networkworld.com/article/2163334/tech-primers/what-can-l2tp-do-for-your-network-.html) calls it "unusual". What is your use case? What are you trying to achieve?

---

From: Ole Troan <[email-masked]>
Date: Wed, 7 Nov 2018 14:45:50 +0700

Naveen,

We have been down this road before with
https://tools.ietf.org/html/draft-haberman-ipngwg-auto-prefix-02

Which is what led to RFC3633.

Is your main motivation for this that there are some platforms that don’t implement DHCP PD?
Seems like the simple solution is to get those to implement it, rather than proposing a redundant standard that no-one has implemented yet.
Unless I am misunderstanding where you want to go with this?

Cheers,
Ole

> On 7 Nov 2018, at 07:59, Naveen Kottapalli <[email-masked]> wrote:
> 
> Hello,
> 
> Subject: New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> URL:            https://www.ietf.org/internet-drafts/draft-naveen-slaac-prefix-management-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-naveen-slaac-prefix-management/
> Htmlized:       https://tools.ietf.org/html/draft-naveen-slaac-prefix-management-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-naveen-slaac-prefix-management
> 
> 
> Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Nov 2018 10:10:43 +0100

> Is your main motivation for this that there are some platforms that don’t implement DHCP PD?

For what is worth: there are some platforms that do not and will not 
implement DHCPv6 PD.

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 7 Nov 2018 16:29:30 +0700

> For what is worth: there are some platforms that do not and will not implement DHCPv6 PD.

And I’m sure platforms that will not implement this…
DHCPv6 PD is just a wire format specified between a requesting router and a delegating router directly connected.
If you cannot implement that, it’s going to be hard to justify implementing the exact same, just with different naming.

Ole

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Nov 2018 22:07:55 +0700

> For what is worth: there are some platforms that do not and will not implement DHCPv6 PD.

That's their choice. Not everyone wants to use prefixes. Those that do will figure out how to discuss the fact with the network.

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 7 Nov 2018 18:27:32 +0000

The only drawback with DHCPv6 PD is that it requires additional messages
in addition to RS/RA; there is nothing wrong with the protocol itself.

It would be better if all autoconfiguration could be conducted in a single
unified message exchange by including DHCPv6 PD directives within the
RS/RA messages.

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Nov 2018 05:05:26 +0700

> On Nov 8, 2018, at 1:27 AM, Templin (US), Fred L <[email-masked]> wrote:
> 

Well, all autoconfguration *is* done using one message - the RA. But prefixes are not auto-configured. RFC 7695, to give a network the ability to distribute /64s within a prefix allocated to it, makes sense (although it is limited to /64s, based on the idea that it is distributing minimal prefixes to LANs) make sense to me. But autoconfiguration using a SLAAC-like algorithm doesn't make sense in my mind, because autoconfiguration of a prefix means more than "pick a number out of the air".

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war, 
Defeated warriors go to war first and then seek to win. 
     Sun Tzu

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 7 Nov 2018 22:50:53 +0000

Fred,

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2018 2:05 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Alexandre Petrescu <[email-masked]>; Ole Troan <[email-masked]>; 6man WG <[email-masked]>; v6ops
> list <[email-masked]>
> Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> 
> 
> 
> Well, all autoconfguration *is* done using one message - the RA. But prefixes are not auto-configured. RFC 7695, to give a network
> the ability to distribute /64s within a prefix allocated to it, makes sense (although it is limited to /64s, based on the idea that it is
> distributing minimal prefixes to LANs) make sense to me. But autoconfiguration using a SLAAC-like algorithm doesn't make sense in
> my mind, because autoconfiguration of a prefix means more than "pick a number out of the air".

Pardon if my terminology slipped. Yes, prefixes are *delegated* (not autoconfigured)
but the idea is to leverage the RS/RA exchange to also facilitate prefix delegation by
embedding DHCPv6 protocol messages within the RS/RA.

Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Nov 2018 07:14:15 +0700

For clarity, my participation in this thread is sans hats. I usually say that, and neglected doing so.

> On Nov 8, 2018, at 5:50 AM, Templin (US), Fred L <[email-masked]> wrote:
> 

And that makes some sense. I have been an advocate for a while of a mechanism that would allow any DHCP configuration element to exist in an RA for the purposes of stateless configuration without having to reinvent the information element, which for a set of things is sensible.

The problem with it in this case is that it presumes that the RA is sent to an individual station and represents an allocation that the station needs and is expecting. In other words, if it is delegating a prefix to a given station, it can't be multicast; it has to be a unicast response to an RS. RA's are in fact often multicast. In this case, the fact that it is embedded in the RA is pretty much pointless; it is in fact a DHCP exchange with a different container, and we have used a stateless configuration mechanism statefully. We have taken an existing, working, mechanism and made it more complex because a certain implementor has an issue with DHCP that other implementors don't seem to have.

That seems like a strange solution. If you want to do something stateful, don't use a stateless protocol. If a unicast exchange is called for (the reason for the RS is that a new station on the network needs configuration now as opposed to "up to seven minutes from now", and can trigger the same message it would get periodically, but upon request). If you want to execute the function of a protocol to obtain a stateful delegation, don't embed the protocol in another protocol that is stateless.
--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Nov 2018 07:18:32 +0700

Another thing to bear in mind is that DHCPv6 RA is normally a four-packet
exchange, and the reason for this is to make sure the client actually got
the prefix.   Take away the four packet exchange, as you must do with
RA/RS, and you may find that it's easier to run the server out of prefixes,
either accidentally or on purpose.

On Thu, Nov 8, 2018 at 7:15 AM Fred Baker <[email-masked]> wrote:

> And that makes some sense. I have been an advocate for a while of a
> mechanism that would allow any DHCP configuration element to exist in an RA
> for the purposes of stateless configuration without having to reinvent the
> information element, which for a set of things is sensible.
>
> The problem with it in this case is that it presumes that the RA is sent
> to an individual station and represents an allocation that the station
> needs and is expecting. In other words, if it is delegating a prefix to a
> given station, it can't be multicast; it has to be a unicast response to an
> RS. RA's are in fact often multicast. In this case, the fact that it is
> embedded in the RA is pretty much pointless; it is in fact a DHCP exchange
> with a different container, and we have used a stateless configuration
> mechanism statefully. We have taken an existing, working, mechanism and
> made it more complex because a certain implementor has an issue with DHCP
> that other implementors don't seem to have.
>
> That seems like a strange solution. If you want to do something stateful,
> don't use a stateless protocol. If a unicast exchange is called for (the
> reason for the RS is that a new station on the network needs configuration
> now as opposed to "up to seven minutes from now", and can trigger the same
> message it would get periodically, but upon request). If you want to
> execute the function of a protocol to obtain a stateful delegation, don't
> embed the protocol in another protocol that is stateless.
>
> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Nov 2018 12:39:14 +0100

Le 07/11/2018 à 23:05, Fred Baker a écrit :
>> The only drawback with DHCPv6 PD is that it requires additional
>> messages in addition to RS/RA; there is nothing wrong with the
>> protocol itself.
>> 
>> It would be better if all autoconfiguration could be conducted in a
>> single unified message exchange by including DHCPv6 PD directives
>> within the RS/RA messages.
>> 
>> Thanks - Fred
> 
> Well, all autoconfguration *is* done using one message - the RA. But
> prefixes are not auto-configured.

This makes think what you want is to make prefix autoconfiguration like 
address allocation, in SLAAC; the equivalent is plen==56 in RA and a 
'subnet ID' to be formed by the Host between positions 56 and 64, "out 
of thin air".

None of this does exists either (SLAAC works only with plen 64 because 
IID must be 64, and Subnet IDs are not formed out of thin air).

> RFC 7695, to give a network the
> ability to distribute /64s within a prefix allocated to it, makes
> sense (alrthough it is limited to /64s, based on the idea that it is
> distributing minimal prefixes to LANs) make sense to me.

Limited to /64.

> But
> autoconfiguration using a SLAAC-like algorithm doesn't make sense in

_Could_ be like that "pick a number out of the air", if a document 
described it and implementation did it.

(it's not what this draft describes now).

Alex
> Defeated warriors go to war first and then seek to win. Sun Tzu
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Nov 2018 17:00:41 +0100

> DHCPv6 PD is just a wire format specified between a requesting router and a delegating router directly connected.

In principle yes: DHCPv6-PD just a different wire format than doing PD 
in SLAAC-PD.

However, the IETF Best Current Practice RFC7934 clearly recommends SLAAC 
at a premium, against DHCP, in order to deliver more addresses to Hosts.

As such, it is difficult to understand that PD be it in SLAAC or in DHCP 
is just a different wire format.

Were it to be just a different wire format then that RFC would at least 
_some_ times put DHCP before SLAAC (currently that RFC puts always SLAAC 
first in its recommendations).

> If you cannot implement that, it’s going to be hard to justify implementing the exact same, just with different naming.

Rather than politicizing, we would ask the implementer whether it is 
easy for her/him to make an update to the Gateway that implements this 
draft.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 8 Nov 2018 16:06:42 +0000

Hi Fred,

Including the DHCPv6 option does not make the RS/RA exchange more complex.
If the router receiving the RS does not recognize the DHCPv6 option it simply ignores
the option and returns an RA without including a DHCPv6 option. If the router *does*
recognize the DHCPv6 option, it statelessly relays the message to the DHCPv6 server
which does what a DHCPv6 server is designed to do. The router then sends the
corresponding RA back as unicast as permitted by RFC4861.

The fact that the IPv6 ND and DHCPv6 information are included in the same RS/RA
containers is a good thing. It is a single message exchange with a single round-trip
instead of multiple - a unified service. And, the benefit is not limited to corner cases
but is good for any sort of links.

Thanks - Fred

> Sent: Wednesday, November 07, 2018 4:14 PM
> And that makes some sense. I have been an advocate for a while of a mechanism that would allow any DHCP configuration element to
> exist in an RA for the purposes of stateless configuration without having to reinvent the information element, which for a set of things
> is sensible.
> 
> The problem with it in this case is that it presumes that the RA is sent to an individual station and represents an allocation that the
> station needs and is expecting. In other words, if it is delegating a prefix to a given station, it can't be multicast; it has to be a unicast
> response to an RS. RA's are in fact often multicast. In this case, the fact that it is embedded in the RA is pretty much pointless; it is in
> fact a DHCP exchange with a different container, and we have used a stateless configuration mechanism statefully. We have taken an
> existing, working, mechanism and made it more complex because a certain implementor has an issue with DHCP that other
> implementors don't seem to have.
> 
> That seems like a strange solution. If you want to do something stateful, don't use a stateless protocol. If a unicast exchange is called
> for (the reason for the RS is that a new station on the network needs configuration now as opposed to "up to seven minutes from
> now", and can trigger the same message it would get periodically, but upon request). If you want to execute the function of a protocol
> to obtain a stateful delegation, don't embed the protocol in another protocol that is stateless.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 8 Nov 2018 16:12:13 +0000

Hi Ted,

This method supports both 2-message and 4-message exchanges, as discussed in
‘draft-templin-6man-dhcpv6-ndopt’. The 2-message exchange is conducted as a
single RS/RA (with embedded DHCPv6 message). The 4-message exchange is
conducted as two back-to-back RS/RA exchanges.

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, November 07, 2018 4:19 PM
To: Fred Baker <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; [email-masked]; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

Another thing to bear in mind is that DHCPv6 RA is normally a four-packet exchange, and the reason for this is to make sure the client actually got the prefix.   Take away the four packet exchange, as you must do with RA/RS, and you may find that it's easier to run the server out of prefixes, either accidentally or on purpose.

On Thu, Nov 8, 2018 at 7:15 AM Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
For clarity, my participation in this thread is sans hats. I usually say that, and neglected doing so.

> On Nov 8, 2018, at 5:50 AM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 8 Nov 2018 23:02:19 +0530

Hello Fred,

Please find comments inline.

Yours,
Naveen.

On Wed, 7 Nov 2018 at 08:08, Fred Baker <[email-masked]> wrote:

> > 1. Soliciting a prefix of specific length.  The length could be of
> either /64 bit prefix (which would generally be solicited by nodes) or non
> /64 bit prefix (which would generally be solicited by either CPE or
> downstream routers).
>
> SLAAC doesn't "solicit" anything. If you want a prefix with any specific
> attributes, you're in the territory of RFC 3633.
>
Naveen] SLAAC as a protocol doesn't solicit anything.  It's the devices
requirement to solicit something using SLAAC as a messaging system.  Am not
sure why would soliciting anything would be under RFC3633 territory.  Take
the example of a gateway where when a device move from one tunnel to other,
the device context in the gateway is removed and recreated.  When this
happens, there is no guarantee that the device gets the same prefix that it
is using till mobility.  Unless the same prefix is received, all the
existing data sessions that are open in the device has to close and
reestablish.

>
> > 2. Releasing the prefixes that are no more used by the device.  This
> could be equally important for the routers who assigned the prefix to make
> the unused prefixes available for other nodes.
>
Naveen] It is the device's graceful action to release the prefix that it
got through RA.  It is through SLAAC message system this is conveyed to the
router to free the resources allocated for the device.

>
> > To achieve the above objectives, a ND based message protocol is
> introduced in the below draft that does what a DHCPv6 node do; without
> introducing any new message types or new option types or flag types.
> >
> The second is that "autoconfiguration" is a bit different than anything
> that one might solicit from or release to a network. For example, with
> addresses, routing is handled by the router that advertised the prefix in
> its RA (and maybe by other routers); when one solicits and starts to use a
> prefix, one needs to advertise it in routing, which means that one is going
> to need to implement and advertise some routing protocol.
>
> Third - L2TP is a bit dated. Maybe that's the reason for the 2001 date on
> the draft. A 2013 article (
> https://www.networkworld.com/article/2163334/tech-primers/what-can-l2tp-do-for-your-network-.html)
> calls it "unusual". What is your use case? What are you trying to achieve?
>

Naveen] My use case is like this.  We are a gateway vendor and our boxes
are in field since last 4-5 years; we are going to have our own CPEs which
connect to our gateway boxes.  These CPEs are pre-programmed with the
number of devices that they support in downstream side.  And when these
CPEs come up, they get the prefix that has to be delegated over to
downstream nodes.  As of now there is no support for doing DHCPv6 PD on the
CPEs.  Also, since last 4-5 years no requirement came from our existing
customers who are extensively using our gateways to support DHCPv6-PD.

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 8 Nov 2018 23:08:45 +0530

Hello Ole,

I agree to some extent that DHCPv6 is a format on wire.  But am sure it
would consume more resources at router to support DHCPv6 as a whole along
with SLAAC.

Yours,
Naveen.

On Wed, 7 Nov 2018 at 14:59, Ole Troan <[email-masked]> wrote:

> If you cannot implement that, it’s going to be hard to justify
> implementing the exact same, just with different naming.
>
> Ole
>
> >> Seems like the simple solution is to get those to implement it, rather
> than proposing a redundant standard that no-one has implemented yet.

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 8 Nov 2018 23:10:32 +0530

Hello Fred,

Prefixes gives liberty to devices to leverage on the number of address it
can use.  Similarly, prefixes eases the job of routers w.r.t routing.  Am I
wrong?

Yours,
Naveen.

On Wed, 7 Nov 2018 at 20:38, Fred Baker <[email-masked]> wrote:

> That's their choice. Not everyone wants to use prefixes. Those that do
> will figure out how to discuss the fact with the network.
>
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 12 Nov 2018 10:39:36 +0100

Naveen,

> I agree to some extent that DHCPv6 is a format on wire.  But am sure it would consume more resources at router to support DHCPv6 as a whole along with SLAAC.

Prefix delegation is quite different from SLAAC.
Regardless this is water under the bridge. Since 2003.

Cheers,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 12 Nov 2018 17:59:40 +0000

Hi Ole,

> From: v6ops [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Monday, November 12, 2018 1:40 AM
> To: Naveen Kottapalli <[email-masked]>
> Cc: 6man WG <[email-masked]>; v6ops list <[email-masked]>

So I can understand this comment, the water under the bridge refers to the
selection of DHCPv6 PD as the protocol for prefix delegation. Is that what
you were meaning to say?

Thanks - Fred

> > >>> 1. Soliciting a prefix of specific length.  The length could be of either /64 bit prefix (which would generally be solicited by nodes)
> or non /64 bit prefix (which would generally be solicited by either CPE or downstream routers).
> > >>> 2. Releasing the prefixes that are no more used by the device.  This could be equally important for the routers who assigned the
> prefix to make the unused prefixes available for other nodes.
> > >>>
> > >>> To achieve the above objectives, a ND based message protocol is introduced in the below draft that does what a DHCPv6 node
> do; without introducing any new message types or new option types or flag types.
> > >>>

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Nov 2018 08:56:50 +0100

Fred,

> selection of DHCPv6 PD as the protocol for prefix delegation. Is that what

Sure. The value proposition of something new, has to be different than “just different wrapping”.

We are still struggling with “permissionless extensions” of an IPv6 network. Something that solved that problem, would be a lot more interesting to talk about.

Cheers,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Nov 2018 16:34:53 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Monday, November 12, 2018 11:57 PM
> Cc: Naveen Kottapalli <[email-masked]>; 6man WG <[email-masked]>; v6ops list <[email-masked]>
> >>> I agree to some extent that DHCPv6 is a format on wire.  But am sure it would consume more resources at router to support
> DHCPv6
> >> as a whole along with SLAAC.
> >>
> Sure.

OK, so you are saying that DHCPv6 is *the* chosen protocol for Prefix Delegation
and there shall be no alternate IPv6 ND-based protocol in addition to that. I don't
mind a statement like that, but would the community agree with it?

> The value proposition of something new, has to be different than “just different wrapping”.

By "different wrapping", are you are talking about non-DHCPv6 protocol proposals?
If not, if you mean to say that the idea of including a DHCPv6 option in RS/RA messages
is "just a different wrapping", then that is not entirely true. By including both the IPv6
ND and DHCPv6 functions in a single message exchange, there are fewer messages
and fewer round trips. That in itself is interesting.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Nov 2018 18:38:07 +0100

Fred,

> On 13 Nov 2018, at 17:34, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Ole,
> 

In general we as a community try to avoid providing multiple equivalent solutions to the same problem. Sometimes we fail. 
> and fewer round trips. That in itself is interesting.

Don’t really see that as interesting. You will not save a round trip, since the two protocols don’t depend on each other. 

Different wrapping. As in exactly same protocol semantics, just options in ND instead of DHCP. 

Cheers 
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Nov 2018 18:25:57 +0000

Ole,

> Sent: Tuesday, November 13, 2018 9:38 AM

But, do you assert that DHCPv6 is the one and only solution?

> Don’t really see that as interesting. You will not save a round trip, since the two protocols don’t depend on each other.

This gets us back to the M&O bits where there is a cross-dependence between the two
protocols. Historically, you are supposed to wait until the RS/RA exchange and check the
M&O bits before invoking DHCPv6 (two round trips). Are you saying that that is no longer
the case? Have we declared that the M&O bits are deprecated?

It is also important that there are fewer messages - two instead of four. That matters
a great deal on low end links.

> Different wrapping. As in exactly same protocol semantics, just options in ND instead of DHCP.

No, the options in RS/RA are exactly DHCPv6 - they are not different than DHCPv6.
That is the whole point.

Thanks - Fred

> Cheers
> Ole
> 
> 
> >
> > Thanks - Fred
> >
> >> We are still struggling with “permissionless extensions” of an IPv6 network. Something that solved that problem, would be a lot
> more
> >> interesting to talk about.
> >>
> >> Cheers,
> >> Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Nov 2018 19:35:33 +0100

> On 13 Nov 2018, at 19:25, Templin (US), Fred L <[email-masked]> wrote:
> 
> Ole,
> 

I am saying that solving a problem that is already solved is a waste of time and resources. 
Now if you install could solve a problem where we don’t have a satisfactory solution...

> the case? Have we declared that the M&O bits are deprecated?

DHCPv6 PD has never had any dependency on the M&O bits. PD is a protocol between routers. 

> a great deal on low end links.

I would like to see the maths behind that. 
Use header compression then. 

> No, the options in RS/RA are exactly DHCPv6 - they are not different than DHCPv6.

Right. I am sorry but I struggle getting why that is valuable. ND is also a one to many protocol. That’s not suitable for per-router delegation. 

Cheers 
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Nov 2018 18:52:35 +0000

HI Ole,

> Sent: Tuesday, November 13, 2018 10:36 AM

OK, then I will say it - DHCPv6 is the one and only solution to Prefix Delegation
*in cases where a dynamic Prefix Delegation protocol is needed*. (I add this
qualification because 'draft-templin-v6ops-pdhost' lists other non-protocol
alternatives for a node receiving a prefix delegation.)

> DHCPv6 PD has never had any dependency on the M&O bits. PD is a protocol between routers.

OK, then let's ignore the M&O bits - I am fine with that.

> Use header compression then.

It isn't only a question of how many bytes - the question is moreso how
many channel accesses are necessary. On some links, sending everything in
a single channel access is less prone to collisions than requiring multiple
channel accesses.

Think about CB radio - after you say "breaker, breaker one-nine" you get
to say as much as you want (within reason) without having to undergo
channel contention multiple times. (That is not to say that common data
links function the same as CB radio, but they do have their CSMA protocols
for making sure they don't step on someone else's transmission.)

> Right. I am sorry but I struggle getting why that is valuable. ND is also a one to many protocol. That’s not suitable for per-router

IPv6 ND messages are permitted to be sent as unicast (one-to-one). In this
case, the presence of a DHCPv6 option in the RS message is indication that
the RA is to be returned via unicast.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Nov 2018 08:36:50 +1300

> alternatives for a node receiving a prefix delegation.)

I'm not disagreeing that DHCPv6-PD is the current IETF solution, but there
are some subtleties:

1) Since there are no protocol police, you can't actually stop people
using some other method of prefix delegation, which would simply appear
to be an out-of-band or "manual" mechanism as far as the IETF protocols
are concerned.

2) We did think about this question a bit while developing 
https://tools.ietf.org/html/draft-ietf-anima-prefix-management-07
(which is approved and in the RFC Editor queue waiting for missing
references). The appendix A2 is supposed to show how a prefix
management system would interface to DHCPv6-PD at the edges of an
autonomic network. I think you'd find something similar in any sort
of coordinated prefix management scheme.

3) A similar situation arises in HNCP:
https://tools.ietf.org/html/rfc7788#section-6.3.4

   Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Nov 2018 20:51:34 +0100

Brian,

Absolutely. When we think of prefix delegation. It is the delegation of an address block from one administrative domain to another. Aka the fax replacement. HNCP solves a very different problem that DHCPv6 is unsuitable for.
Basically anything involving a topology is not good use of DHCPv6. Unless you want to build spanning trees with DHCP relays. Of course ND is equally ill-suited for that. 

Cheers 
Ole

> On 13 Nov 2018, at 20:36, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 13 Nov 2018 20:34:19 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2018 11:37 AM
> To: Templin (US), Fred L <[email-masked]>; Ole Troan <[email-masked]>
> Cc: v6ops list <[email-masked]>; 6man WG <[email-masked]>

Right, I wanted to be careful in how I worded my message based on our
knowledge of other non-router methods (including anima) which we
captured in 'draft-templin-v6ops-pdhost'. From that document:

"10.  Prefix Delegation Services

   Selection of prefix delegation services must be considered according
   to specific use cases.  An example service is that offered by DHCPv6
   [RFC3633].  An alternative service based on IPv6 ND messaging has
   also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit].

   Other, non-router, mechanisms may exist, such as proprietary IPAMs,
   [I-D.ietf-anima-prefix-management] and
   [I-D.sun-casm-address-pool-management-yang]."

Does this still ring true, or do we need to make some adjustments based
on these recent discussions?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Nov 2018 11:00:38 +1300

in line..
> on these recent discussions?

I think it's still true, although as Ole and I said, proposals such as
anima-prefix-management, CASM amd HNCP do recognize DHCPv6-PD as the
boundary mechanism. On the other hand, naveen-slaac-prefix-management
intentionally competes with DHCPv6-PD, which is a different discussiion.

    Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 14 Nov 2018 15:38:56 +0000

Ole,

> a single channel access is less prone to collisions than requiring multiple

Fewer messages are fewer messages. On congested links with lots of
channel contention that is an important consideration.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Nov 2018 17:31:36 +0100

Fred,

> On 14 Nov 2018, at 16:38, Templin (US), Fred L <[email-masked]> wrote:
> 
> Ole,
> 

If this is such a big concern, what are you doing with all the other ND chatter?

Perhaps you should drop ND on these links and do only DHCP? :-)

Or preconfigure everything so you don’t need to send any packets at all?

Do you have data on the behavior of this link type, showing the effects you are referring to?

Cheers 
Ole

---

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

Hi Ole,

> Sent: Wednesday, November 14, 2018 8:32 AM

DAD is disabled, because there is operational assurance that addresses will
be unique. NUD is not needed either. All that is needed is RS/RA.

> Perhaps you should drop ND on these links and do only DHCP? :-)

DHCPv6 does not deliver default router lifetime, on-link prefix information,
SLLAO, nor any other parameters carried uniquely by RS/RA. We need
that information.

> Or preconfigure everything so you don’t need to send any packets at all?

There are use cases where a mobile node such as an airplane is pre-provisioned
with a Mobile Network Prefix (MNP). But, when the node comes onto the
network it still needs to register its MNP with the network so that the network
will set up the correct routing information. DHCPv6 PD is a good way to do that.

> Do you have data on the behavior of this link type, showing the effects you are referring to?

The reality for today and into the near future is that we have 32Kbps for VHF
terrestrial cellular and 256KB for SATCOM. For the longer term, there may be
new SATCOM services as well as 1Mbps for a future terrestrial cellular link that
may or may not ever be deployed.

But, what is good in this environment applies more broadly to other more
robust environments. Fewer messages is still fewer messages.

Thanks - Fred

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 15 Nov 2018 22:47:36 +0530

Hello all,

To be honest, there is no intention to compete with other existing
protocols.  I see that SLAAC has got some gaps w.r.t the functionality and
the same is covered in the draft.  And I see the cases where this draft
solves real time problems where the existing *bridge* itself is not usable.

@Ole / @Fred / others: If a device soliciting something from the router
using RS is considered as intruding into other territory, IMHO it's
very *unfair
way of evaluating*.  For that matter whether a PIO is included in RS or
not, a device is soliciting the information from router.  When this draft
solves the problems it cannot be put down just by saying it as a redundant
to another standard, while actually it is not.

If a device soliciting required information using the existing protocol
standards without new message types or option types or flags itself is
treated as a wrapper or redundant for other standards, aren't there
overlapping options in both SLAAC and DHCPv6 that can be sent to the
devices?  For that matter what about the complete SLAAC and DHCPv6?  Am I
wrong in quoting that both DHCPv6 and SLAAC are redundant protocols to each
other?

I also agree that multiple attempts were made by many respected members of
the forum to bring in similar changes to whatever my current draft
suggested.  But not sure why they couldn't become standards.  It shows the
need of devices that are looking for a solution and am sure people keep
inventing round-about solutions for the same.

If someone sees a problem in mentioning DHCPv6 inside the draft, please
suggest another change for that.

I understand that the forum has finite reservations on providing extensions
to existing protocols.  But I request the forum and WG chairs to evaluate
this draft fairly and technically.

Yours,
Naveen.

On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter <[email-masked]>
wrote:

> >> Subject: Re: [v6ops] New Version Notification for
> >>>> Cc: Naveen Kottapalli <[email-masked]>; 6man WG <
> [email-masked]>; v6ops list <[email-masked]>
> >>>> Subject: Re: [v6ops] New Version Notification for
> >>>>>> Cc: Naveen Kottapalli <[email-masked]>; 6man WG <
> [email-masked]>; v6ops list <[email-masked]>
> >>>>>> Subject: Re: [v6ops] New Version Notification for
> >>>>>>>> Cc: Naveen Kottapalli <[email-masked]>; 6man WG <
> [email-masked]>; v6ops list <[email-masked]>
> >>>>>>>> Subject: Re: [v6ops] New Version Notification for
> >>>>>>>>>>> I agree to some extent that DHCPv6 is a format on wire.  But
> am sure it would consume more resources at router to
> >> support
> >>>>>>>> DHCPv6
> >>>>>> In general we as a community try to avoid providing multiple
> equivalent solutions to the same problem. Sometimes we fail.
> >>>>>
> >>>>>> Don’t really see that as interesting. You will not save a round
> trip, since the two protocols don’t depend on each other.
> >>>>>
> >>>> Right. I am sorry but I struggle getting why that is valuable. ND is
> also a one to many protocol. That’s not suitable for per-router
> >>>> delegation.
> >>>
> >>>>>>>> We are still struggling with “permissionless extensions” of an
> IPv6 network. Something that solved that problem, would be a
> >> lot
> >>>>>> more

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Nov 2018 17:43:42 +0000

Naveen,

The idea of including a DHCPv6 message option in IPv6 ND RS/RA messages requires
a *new option* to go along with an already existing protocol (namely, DHCPv6).
The idea your draft builds on uses an existing IPv6 ND option but requires a
*new protocol* that is not fully specified in your draft yet. My feeling is that once
the new protocol is fully fleshed out it would look very much like DHCPv6, and
some people have said that they do not want new protocols.

I am actually beyond the point of caring whether the protocol should be DHCPv6,
but do we also need a new non-DHCPv6 protocol that looks a lot like DHCPv6?

Thanks - Fred

From: Naveen Kottapalli [mailto:[email-masked]]
Sent: Thursday, November 15, 2018 9:18 AM
To: Brian E Carpenter <[email-masked]>
Cc: Templin (US), Fred L <[email-masked]>; [email-masked]; v6ops list <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

Hello all,

To be honest, there is no intention to compete with other existing protocols.  I see that SLAAC has got some gaps w.r.t the functionality and the same is covered in the draft.  And I see the cases where this draft solves real time problems where the existing bridge itself is not usable.

@Ole / @Fred / others: If a device soliciting something from the router using RS is considered as intruding into other territory, IMHO it's very unfair way of evaluating.  For that matter whether a PIO is included in RS or not, a device is soliciting the information from router.  When this draft solves the problems it cannot be put down just by saying it as a redundant to another standard, while actually it is not.

If a device soliciting required information using the existing protocol standards without new message types or option types or flags itself is treated as a wrapper or redundant for other standards, aren't there overlapping options in both SLAAC and DHCPv6 that can be sent to the devices?  For that matter what about the complete SLAAC and DHCPv6?  Am I wrong in quoting that both DHCPv6 and SLAAC are redundant protocols to each other?

I also agree that multiple attempts were made by many respected members of the forum to bring in similar changes to whatever my current draft suggested.  But not sure why they couldn't become standards.  It shows the need of devices that are looking for a solution and am sure people keep inventing round-about solutions for the same.

If someone sees a problem in mentioning DHCPv6 inside the draft, please suggest another change for that.

I understand that the forum has finite reservations on providing extensions to existing protocols.  But I request the forum and WG chairs to evaluate this draft fairly and technically.

Yours,
Naveen.

On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
in line..
On 2018-11-14 09:34, Templin (US), Fred L wrote:
>> From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
>> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; Ole Troan <[email-masked]<mailto:[email-masked]>>
>> Cc: v6ops list <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
>>>> From: Ole Troan [mailto:[email-masked]<mailto:[email-masked]>]
>>>> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
>>>>> On 13 Nov 2018, at 19:25, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>> Ole,
>>>>>
>>>>>> From: Ole Troan [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
>>>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
>>>>>>> On 13 Nov 2018, at 17:34, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>> Hi Ole,
>>>>>>>
>>>>>>>> From: Ole Troan [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>>> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
>>>>>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 15 Nov 2018 19:50:56 +0100

Naveen,

Let me quote from RFC1958:

3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

What problem are you trying to solve with your proposal which isn’t covered by existing solutions?

Cheers,
Ole

> On 15 Nov 2018, at 18:17, Naveen Kottapalli <[email-masked]> wrote:
> 
> Hello all,
> 
> On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter <[email-masked]> wrote:
> in line..

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Nov 2018 08:37:13 +1300

> but do we also need a new non-DHCPv6 protocol that looks a lot like DHCPv6?

I realised when looking at this draft that DHCPv6 has one property that
RS/RA completely lacks: a transaction ID. I don't see how we can build
any kind of resource allocation mechanism without some form of transactional
integrity. Prefix delegation is of course a form of resource allocation.
So that is a fundamental difference between DHCPv6 and RS/RA.

   Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 15 Nov 2018 19:41:35 +0000

Hi Brian,

> Sent: Thursday, November 15, 2018 11:37 AM
> To: Templin (US), Fred L <[email-masked]>; Naveen Kottapalli <[email-masked]>
> Cc: [email-masked]; v6ops list <[email-masked]>; 6man WG <[email-masked]>
> RS/RA completely lacks: a transaction ID.

The SEND "Nonce" option can be used to encode a transaction ID, but again
this would constitute a new protocol.

> I don't see how we can build

In addition to transaction ID, the exchange requires Identifications for the
host and router. In DHCPv6, these are called "DUIDs" - there is no corresponding
feature in IPv6 ND, although the link-layer addresses could potentially be
leveraged. Again, a new protocol.

Thanks - Fred
[email-masked]

> > To be honest, there is no intention to compete with other existing protocols.  I see that SLAAC has got some gaps w.r.t the
> functionality and the same is covered in the draft.  And I see the cases where this draft solves real time problems where the existing
> bridge itself is not usable.
> >
> > @Ole / @Fred / others: If a device soliciting something from the router using RS is considered as intruding into other territory, IMHO
> it's very unfair way of evaluating.  For that matter whether a PIO is included in RS or not, a device is soliciting the information from
> router.  When this draft solves the problems it cannot be put down just by saying it as a redundant to another standard, while actually
> it is not.
> >
> > If a device soliciting required information using the existing protocol standards without new message types or option types or flags
> itself is treated as a wrapper or redundant for other standards, aren't there overlapping options in both SLAAC and DHCPv6 that can
> be sent to the devices?  For that matter what about the complete SLAAC and DHCPv6?  Am I wrong in quoting that both DHCPv6 and
> SLAAC are redundant protocols to each other?
> >
> > I also agree that multiple attempts were made by many respected members of the forum to bring in similar changes to whatever my
> current draft suggested.  But not sure why they couldn't become standards.  It shows the need of devices that are looking for a
> solution and am sure people keep inventing round-about solutions for the same.
> >
> > I understand that the forum has finite reservations on providing extensions to existing protocols.  But I request the forum and WG
> chairs to evaluate this draft fairly and technically.
> >
> > Yours,
> > Naveen.
> >
> >
> >>> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; Ole Troan
> <[email-masked]<mailto:[email-masked]>>
> >>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; 6man WG
> <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
> >>>>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; 6man WG
> <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
> >>>>>>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; 6man WG
> <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>
> >>>>>>>>> We are still struggling with “permissionless extensions” of an IPv6 network. Something that solved that problem, would
> be a
> >>> lot
> >>>>>>> more

---

From: Naveen Kottapalli <[email-masked]>
Date: Sat, 17 Nov 2018 22:46:02 +0530

Hello Ole,

Following are the things that am trying to solve.

1. I can't sell oranges when apples are asked for.
2. Improving SLAAC as a protocol by providing options like soliciting a
prefix of certain length; releasing or declining a prefix (this is equally
more important for the protocol perspective itself as a prefix is an
important resource for the router).

Please let me know which of the above points you think are not valid.

Thanks & Regards,
Naveen

On Fri, 16 Nov 2018, 00:21 Ole Troan <[email-masked] wrote:

> solves real time problems where the existing bridge itself is not usable.
> >
> using RS is considered as intruding into other territory, IMHO it's very
> unfair way of evaluating.  For that matter whether a PIO is included in RS
> or not, a device is soliciting the information from router.  When this
> draft solves the problems it cannot be put down just by saying it as a
> redundant to another standard, while actually it is not.
> >
> > I also agree that multiple attempts were made by many respected members
> of the forum to bring in similar changes to whatever my current draft
> > I understand that the forum has finite reservations on providing
> extensions to existing protocols.  But I request the forum and WG chairs to
> evaluate this draft fairly and technically.
> >
> > Yours,
> > Naveen.
> >
> >
> > >>>> Right. I am sorry but I struggle getting why that is valuable. ND
> is also a one to many protocol. That’s not suitable for per-router
> > >>>> delegation.
> > >>>

---

From: Ole Troan <[email-masked]>
Date: Sat, 17 Nov 2018 18:35:13 +0100

Hi Naveen,

While the purpose of the proposal might be obvious to you, it might not be for the rest of us. 

Can you please describe the problem you are trying to solve?

Can you please describe how existing solutions do not solve your problem?

Note, “PD is not supported in SLAAC” is not the problem description I am hoping for. 

Cheers 
Ole

> On 17 Nov 2018, at 18:16, Naveen Kottapalli <[email-masked]> wrote:
> 
> Hello Ole,
> 
> 2. Improving SLAAC as a protocol by providing options like soliciting a prefix of certain length; releasing or declining a prefix (this is equally more important for the protocol perspective itself as a prefix is an important resource for the router).
>

---

From: Naveen Kottapalli <[email-masked]>
Date: Sat, 17 Nov 2018 23:10:59 +0530

Hello Brian,

Whether it's a prefix delegation or allocation, it's a resource allocation
from both the host / CPE or a router perspective. Do you see that missing
transaction ID in RS/RA as a mandatory requirement for SLAAC to function
even with proposed protocol?

Also am not sure if am wrong in quoting that *delegation* is the term
coined to mimic SLAAC behavior of prefix allocation from a sub pool.

Please correct me if am wrong.

Thanks & Regards,
Naveen

On Fri, 16 Nov 2018, 01:07 Brian E Carpenter <[email-masked]
wrote:

> > Cc: Templin (US), Fred L <[email-masked]>;
> [email-masked]; v6ops list <[email-masked]>; 6man WG <[email-masked]>
> > On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter <
> [email-masked]<mailto:[email-masked]>> wrote:
> > in line..
> >>> To: Templin (US), Fred L <[email-masked]<mailto:
> [email-masked]>>; Ole Troan <[email-masked]<mailto:
> [email-masked]>>
> >>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:
> [email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>;
> v6ops list <[email-masked]<mailto:[email-masked]>>
> >>>>>> On 13 Nov 2018, at 19:25, Templin (US), Fred L <
> [email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>
> >>>>>> Ole,
> >>>>>>
> >>>>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:
> [email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>;
> v6ops list <[email-masked]<mailto:[email-masked]>>
> >>>>>>>> On 13 Nov 2018, at 17:34, Templin (US), Fred L <
> [email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Ole,
> >>>>>>>>
> >>>>>>>>> Cc: Naveen Kottapalli <[email-masked]<mailto:
> [email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>;
> v6ops list <[email-masked]<mailto:[email-masked]>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Nov 2018 08:46:52 +1300

> even with proposed protocol?

Yes. Without a transaction ID, a nonce, or some equivalent mecahnism
there is no way to correlate the request and response unambiguously.
In particular your proposal doesn't distinguish between an unsolicited
unicast RA announcing a prefix and a solicited unicast RA assigning a
prefix, which are totally different actions.

Handing out resources with a single message exchange is bad practice
anyway; if the response is lost, the resource is lost for ever. You really
need some kind of two-phase commit. The standard RA doesn't have this
problem because it's an *announcement* not an *assignment*, and it is
repeated at a reasonable frequency, so a lost message doesn't matter.

(A device ID, as also used in DHCPv6, doesn't seem to be essential
in the same way, but would be needed if an authorisation or
logging mechanism is needed, i.e. to answer "Is it OK to give a /56
prefix to this box?" or "Which box got that prefix?" you need an
identifier for the box.)

> coined to mimic SLAAC behavior of prefix allocation from a sub pool.

"Delegation", "allocation" or "assignment" are all fundamentally the
same, and are all different from the simple announcement function of a
normal RA. Your proposal changes an announcement protocol into a
management protocol. That's the thing that Ole is asking you to justify.
Why do that?

    Brian

>> [email-masked]>>
>> [email-masked]>>
>> [email-masked]>>

---

From: Naveen Kottapalli <[email-masked]>
Date: Sun, 18 Nov 2018 23:21:48 +0530

Hello Ole,

Thanks & Regards,
Naveen

> Can you please describe the problem you are trying to solve?
Naveen] Below is the description of problems that are being tried to solve:
1. Solicit any prefix of pre configured length using RS / RA. We can have
it implemented in both of our CPE and router. But the solution wouldn't be
compliant or interoperable.
2. Some of the prefixes that were assigned to hosts by our router are
lingering though the host interface is brought down and the prefix isn't
used anymore.
3. Hosts during mobility are losing the existing ongoing traffic sessions
due to prefix change. This is because when the gateway detects mobility to
a different tunnel the existing session will be cleared and a new session
entry is created. During this process there is no guarantee that the same
prefix will be assigned back to the device.

> Can you please describe how existing solutions do not solve your problem?
Naveen] All the prefixes were assigned using SLAAC and there is no solution
till date to solicit or release a specific prefix. It's not just specific
prefix, but the only existing solution to get a non /64 prefix is only
through DHCPv6, which can't be done in the CPE.

> Note, “PD is not supported in SLAAC” is not the problem description I am
Naveen] Unfortunately yes for the use case where prefix length less than
64. I see this as more like soliciting a prefix pool.  All the host / CPE
does is soliciting a prefix of desired length by including existing options
in RS.  But why a host or CPE soliciting a prefix (which is already done by
them) without introducing new message types or options should be a problem?

>> [email-masked]> wrote:
>> > in line..
>> [email-masked]> wrote:
>> > >>>>>
>> > >>>>> Ole,
>> > >>>>>
>> [email-masked]> wrote:
>> > >>>>>>>
>> > >>>>>>> Hi Ole,
>> > >>>>>>>
>> > >>>>>>>>>>> I agree to some extent that DHCPv6 is a format on wire.
>> But am sure it would consume more resources at router to
>> > >> support
>> > >>>>>>>> DHCPv6

---

From: Naveen Kottapalli <[email-masked]>
Date: Sun, 18 Nov 2018 23:23:39 +0530

Hello Brian,

Thanks & Regards,
Naveen

> prefix, which are totally different actions.

Naveen] Am not yet clear on why we should distinguish between unsolicited
and solicited RA.  Do we need to distinguish like that?  As per my current
knowledge any prefix will be allocated or assigned only when RS is received
from node and didn't come across an use case of a router assigning the
prefix unsolicited.  So, since both node and router will have context of
prefix assigned, we can reserve constant numbers like 0 or 0xFFFFFFFF for
nonces included in unsolicited RA. I can add a text saying the use of this
in next version of draft.

> need some kind of two-phase commit.

Naveen] Do we really need this? There are equal amount of chances of losing
a RA or DHCPv6 Avertise / Reply.  A two way commit will induce more delay
in the resource allocation procedure and it might not be required as the
retry mechanism is in place.  I would rather say that the resource is never
lost.  That is because, from router perspective the resource is allocated
even if the message doesn't reach the solicited node.  A device will anyway
retry and a router will always sends a response with the same allocated
prefix.

The standard RA doesn't have this
> repeated at a reasonable frequency, so a lost message doesn't matter.

Naveen] I don't see a difference between the two in my draft. So, didn't
want to distinguish between the two i.e. standard and the one proposed in
this draft.  What kind of difference do you see?

> prefix to this box?" or "Which box got that prefix?" you need an
Naveen] This is mentioned in my draft about whether the routers
configuration allows /56 prefix allocation or not. If not, a router can log
using the mac address of the device.  We too do the same thing in our
router.

> >>> *new protocol* that is not fully specified in your draft yet. My
> feeling
> >> is that once
> >> [email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]
> >>;
> >> [email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]
> >>;
> >> [email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]
> >>;
> >>>>>>> I am saying that solving a problem that is already solved is a
> waste
> >> of time and resources.
> >>>>>>>>>>> The value proposition of something new, has to be different
> than
> >> “just different wrapping”.
> >>>>>>>>>>
> >>>>>>>> This gets us back to the M&O bits where there is a
> cross-dependence
> >> between the two
> >>>>>>>> It is also important that there are fewer messages - two instead
> of
> >> four. That matters
> is
> >>>>>> IPv6 ND messages are permitted to be sent as unicast (one-to-one).
> In
> >> this
> >>>>>> case, the presence of a DHCPv6 option in the RS message is
> indication
> >> that

---

From: Ole Troan <[email-masked]>
Date: Sun, 18 Nov 2018 19:16:08 +0100

Naveen,

I don’t understand the problem description below, nor why it would require a different solution than any of those we already have. 

Does anyone else understand and can translate?

Cheers 
Ole

> On 18 Nov 2018, at 18:51, Naveen Kottapalli <[email-masked]> wrote:
> 
> Hello Ole,
> 
> 1. Solicit any prefix of pre configured length using RS / RA. We can have it implemented in both of our CPE and router. But the solution wouldn't be compliant or interoperable.
> 2. Some of the prefixes that were assigned to hosts by our router are lingering though the host interface is brought down and the prefix isn't used anymore.
> 3. Hosts during mobility are losing the existing ongoing traffic sessions due to prefix change. This is because when the gateway detects mobility to a different tunnel the existing session will be cleared and a new session entry is created. During this process there is no guarantee that the same prefix will be assigned back to the device.
>> 
> Naveen] All the prefixes were assigned using SLAAC and there is no solution till date to solicit or release a specific prefix. It's not just specific prefix, but the only existing solution to get a non /64 prefix is only through DHCPv6, which can't be done in the CPE.
>> 
> Naveen] Unfortunately yes for the use case where prefix length less than 64. I see this as more like soliciting a prefix pool.  All the host / CPE does is soliciting a prefix of desired length by including existing options in RS.  But why a host or CPE soliciting a prefix (which is already done by them) without introducing new message types or options should be a problem?
>> 
>> Cheers 
>> Ole
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Nov 2018 08:34:06 +1300

On 2018-11-19 06:53, Naveen Kottapalli wrote:
> prefix unsolicited.  

Today, no prefixes are assigned on receipt of RS, so I don't understand
your argument. Prefixes are assigned either by configuration or
by DHCPv6-ND.

> So, since both node and router will have context of

But there is no field in an RA for a nonce.

> retry mechanism is in place.  

A retry mechanism is not safe. It might lead to the same prefix being
allocated twice due to lost messages or a race condition. I suggest
that you read up on two-phase commit, which requires a minimum of
four messages.

> I would rather say that the resource is never

But it never knows if the response was received, which is a requirement
for safe resource allocation.

> this draft.  What kind of difference do you see?

As described above. An existing RA says "I route this prefix".
Your RA says "You can use this prefix." That is an utterly different
statement.

> using the mac address of the device.  We too do the same thing in our

/56 is only an example of course. Any length prefix could be requested.
Yes, if you trust the MAC address you could use that as an ID. But
if you use DHCPv6 that problem is already solved.

    Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 19 Nov 2018 15:41:49 +0000

About node identifiers, the only identifier available via RS/RA is the link-layer
address, e.g., through included SLLAOs. But, DHCPv6 offers many types of
identifiers, including link-layer address, link-layer address plus time, enterprise
number, etc. And, it can be extended to support any potential future identifier
type. This may be important in networks where there is a requirement to have
an enterprise-specific manner of managing node identifiers.

About transaction IDs, DHCPv6 messages include a transaction ID in the
message header whereas RS/RA could include a Nonce option and use
that as a transaction ID. Here, there may be an advantage for RS/RA since
the Nonce option can be arbitrarily long whereas the DHCPv6 transaction
ID is only 24 bits. Is this important?

Thanks - Fred

> Sent: Sunday, November 18, 2018 11:34 AM

---

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

BTW, those who are reading Naveen's draft should first read 'draft-templin-6man-dhcpv6-ndopt'.
The ideas of including an identification and transaction ID are thoroughly discussed there, as are
several different options for an RS/RA-based prefix delegation service. In fact, Naveen's draft is
really just a sub-case of 'draft-templin-6man-dhcpv6-ndopt' except with the added ambition to
define protocol message exchanges, i.e., a new protocol.

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Monday, November 19, 2018 7:42 AM
> To: Brian E Carpenter <[email-masked]>; Naveen Kottapalli <[email-masked]>
> Subject: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 20 Nov 2018 23:38:51 +0530

Hello Brian,

Comments inline.

Yours,
Naveen.

> your argument. Prefixes are assigned either by configuration or
Naveen] I would see this as partially true.  As one of the forum member
mentioned, RA does more than advertising the prefix.  Even in our gateway
too prefixes are assigned to subscribers when a RS is received from devices
directly tunneled over GRE.  Consider the case of described in RFC8273,
where the prefixes are assigned to devices upon receipt of RS.  So, it
needn't always be a configuration or DHCPv6 for the prefix allocation or
assignment.

> But there is no field in an RA for a nonce.
Naveen] That is what my draft is proposing.

> that you read up on two-phase commit, which requires a minimum of
Naveen] Agree that a two-phase commit is considerably safe.  This can be a
subject of future study.

> Your RA says "You can use this prefix." That is an utterly different
Naveen] As mentioned in above example, not all routers might not be
eligible to say that "You can use this prefix" (for example, whoever didn't
go for a < /64 prefix allocation).  There must not be a big change in
existing behavior.  Can you please help me understand your comment?

> if you use DHCPv6 that problem is already solved.

Naveen] As I mentioned earlier in my mail, DHCPv6 is not a usable solution
in my case and across all platforms (might be for others too).  That is
reason we see so many drafts were invented by honorable members of the
group to bridge the gap in SLAAC itself.

> >>>>> The idea of including a DHCPv6 message option in IPv6 ND RS/RA
> messages
> >>>> requires
> >>>>> I am actually beyond the point of caring whether the protocol should
> be
> >>>> DHCPv6,
> very
> >>>> unfair way of evaluating.  For that matter whether a PIO is included
> in
> >> RS
> >>>> devices?  For that matter what about the complete SLAAC and DHCPv6?
> Am
> >> I
> >>>>>>> From: Brian E Carpenter [mailto:[email-masked]
> <mailto:
> >>>> [email-masked]>]
> >>>>>>>>>>>>>> selection of DHCPv6 PD as the protocol for prefix
> delegation.
> >>>> Is that what
> >>>>>>>>>>>>>> you were meaning to say?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sure.
> >>>>>>>>>>>>
> >>>>>>>> *in cases where a dynamic Prefix Delegation protocol is needed*.
> (I
> >>>> add this
> >>>>>>> I'm not disagreeing that DHCPv6-PD is the current IETF solution,
> but
> >>>> there
> >>>>>>> are some subtleties:
> >>>>>>>
> >>>>>>>>>>>> is "just a different wrapping", then that is not entirely
> true.
> >>>> By including both the IPv6
> >>>>>>>>>>>> ND and DHCPv6 functions in a single message exchange, there
> are
> >>>> fewer messages
> >>>>>>>>>> protocols. Historically, you are supposed to wait until the
> RS/RA
> >>>> exchange and check the
> >>>>>>>>>> M&O bits before invoking DHCPv6 (two round trips). Are you
> saying
> >>>> that that is no longer
> >>>>>>>> It isn't only a question of how many bytes - the question is
> moreso
> >>>> how
> >>>>>>>> Think about CB radio - after you say "breaker, breaker one-nine"
> you
> >>>> get

---

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 20 Nov 2018 23:44:32 +0530

Hello Ole,

Refined my problem statements below.  Please let me know if this is okay.

Yours,
Naveen.

On Sun, 18 Nov 2018 at 23:46, Ole Troan <[email-masked]> wrote:

> Naveen,
>
> I don’t understand the problem description below, nor why it would require
> a different solution than any of those we already have.
>
> 1. Soliciting any prefix of pre configured length using RS / RA is not
> currently supported.  Lack of this forces the devices to be at disposal of
> routers.  We can have it implemented in both of our CPE and router. But the
> solution wouldn't be compliant or inter-operable.  The reason why existing
> solutions can't be used is mentioned below.
> 2. Lingering SLAAC prefixes at router.  Some of the prefixes that were
> assigned to hosts by our router are lingering though the host interface is
> brought down and the prefix isn't used anymore.
> 3. Devices lose ongoing data connectivity when mobility happens.  Hosts
> during mobility are losing the existing ongoing traffic sessions due to
> SLAAC prefix change. This is because when the gateway detects mobility to a
> different tunnel the existing session will be cleared and a new session
> Naveen] All the prefixes were assigned using SLAAC and there is no
> solution till date to solicit or release a specific prefix. It's not just
> specific prefix, but the only existing solution to get a non /64 prefix is
> only through DHCPv6, which can't be done in the CPE.
>
>>
>>> > @Ole / @Fred / others: If a device soliciting something from the
>>> router using RS is considered as intruding into other territory, IMHO it's
>>> very unfair way of evaluating.  For that matter whether a PIO is included
>>> in RS or not, a device is soliciting the information from router.  When
>>> this draft solves the problems it cannot be put down just by saying it as a
>>> > If a device soliciting required information using the existing
>>> protocol standards without new message types or option types or flags
>>> itself is treated as a wrapper or redundant for other standards, aren't
>>> there overlapping options in both SLAAC and DHCPv6 that can be sent to the
>>> > I also agree that multiple attempts were made by many respected
>>> members of the forum to bring in similar changes to whatever my current
>>> draft suggested.  But not sure why they couldn't become standards.  It
>>> shows the need of devices that are looking for a solution and am sure
>>> people keep inventing round-about solutions for the same.
>>> >
>>> delegation. Is that what
>>> waste of time and resources.
>>> (I add this
>>> but there
>>> than “just different wrapping”.
>>> > >>>>>>>
>>> true. By including both the IPv6
>>> are fewer messages
>>> cross-dependence between the two
>>> RS/RA exchange and check the
>>> saying that that is no longer
>>> of four. That matters
>>> moreso how
>>> you get
>>> In this
>>> indication that
>>> > >>>>>>>> We are still struggling with “permissionless extensions” of
>>> an IPv6 network. Something that solved that problem, would be a
>>> > >> lot
>>> > >>>>>> more

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Nov 2018 09:01:37 +1300

> Comments inline.

The same from me...

> directly tunneled over GRE.  

Can you explain that in more detail? Is that how a homenet would
get a /48 for example?

> Consider the case of described in RFC8273,

There is a very fundamental difference between RFC8273 and your proposal.
In RFC8273 the target host *does not know* that the /64 prefix is
single-use. In no way is that prefix delegated to the host; it is
simply the prefix it may use for forming its own address. (It is not
even marked as an on-link prefix, since the L bit is specified to be
off.)

> Naveen] That is what my draft is proposing.

I must have missed that in the text. Which section?

> existing behavior.  Can you please help me understand your comment?

Only a router that owns a pool of prefixes can delegate them using
DHCPv6-PD, and I don't see why it would be any different for your
proposal.

> group to bridge the gap in SLAAC itself.

If the need is to reproduce all DHCPv6 features inside RS/RA, is there
really a saving in complexity and footprint?

   Brian

>> router
>> protocol
>> members
>> an

---

From: Gert Doering <[email-masked]>
Date: Tue, 20 Nov 2018 21:06:13 +0100

Hi,

> really a saving in complexity and footprint?

This.

And I do not see why a platform that refuses to implement DHCPv6-ND 
today would all of a sudden grow a liking for DHCPv6-disguised-in-RS/RA
(which would need code changes as well).

I do not think this is a useful way to spend energy.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 20:14:23 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Tuesday, November 20, 2018 12:06 PM

We have already implemented DHCPv6-within-RS/RA. Our platform? OpenVPN.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 20:42:30 +0000

> I must have missed that in the text. Which section?

This has already been covered for a long time in 'draft-templin-6man-dhcpv6-ndopt',
which Naveen's draft borrows from. From the introduction:

   'This document proposes methods for combining stateless and stateful
   operations into a single, unified exchange based on IPv6ND messaging
   extensions.  It notes that stateful exchanges should include:

   o  an explicit request for stateful information

   o  the identity of the requesting node

   o  a transaction ID that the requesting node can use to match replies
      with their corresponding requests

   o  any security parameters necessary for the requesting node to
      establish its authorization to receive stateful information'

And, then in Section 3.3 it says:

   'The RS message can
   include a Nonce option [RFC3971] to provide a transaction identifier
   for matching RS and RA messages.'

Thanks - Fred

> Sent: Tuesday, November 20, 2018 12:02 PM
> Cc: Templin (US), Fred L <[email-masked]>; Ole Troan <[email-masked]>; v6ops list <[email-masked]>; 6man WG
> <[email-masked]>

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 21 Nov 2018 07:42:10 +0530

Fred,

Am aware that there are many open source softwares available. But the use
cases that I mentioned in my draft holds good with what I mentioned below.

I agree you suggested to include Nonce in RS / RA. That's why your
contribution is recognized and your name is mentioned in the draft under
*contributors*. But the whole idea of doing something with just RS / RA
with out the need of new option flags or message types was from me which we
discussed in call. If you want we can take this discussion we can take
offline.

Thanks & Regards,
Naveen

On Wed, 21 Nov 2018, 00:22 Templin (US), Fred L <[email-masked]
wrote:

> I don’t understand that; there are a number of very good
> publicly-available DHCPv6
>
> implementations that support prefix delegation today. And, to instrument
> RS/RA to
>
> perform prefix delegation under a new protocol would require a non-trivial
> amount
>
> of new code. So, why not just use DHCPv6?
>
>
>
> Thanks - Fred
>
>
>
> PS Please also do not forget that the idea of using the Nonce as a
> transaction ID
>
>       vessel came from me.
>
>
>
> *From:* Naveen Kottapalli [mailto:[email-masked]]
> *Sent:* Tuesday, November 20, 2018 10:09 AM
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* Templin (US), Fred L <[email-masked]>; Ole Troan <
> [email-masked]>; v6ops list <[email-masked]>; 6man WG <[email-masked]
> >
> *Subject:* Re: [v6ops] New Version Notification for
> On Mon, 19 Nov 2018 at 01:04, Brian E Carpenter <

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 21 Nov 2018 15:22:45 +0530

Hello Brian,

As I think more on usage of "on-link" flag and unsolicited RA, I see the
below corrections might be required in my draft.

1. When the prefix length of < 64 is solicited by a CPE or downstream
router, the "on-link" flag will not make sense from delegating router's
perspective.  It is the CPE or downstream router responsibility to use the
prefix pool and on-link bit as per configuration based on the network
topology it is catering to.
2. When the prefix length of < 64 is solicited by a CPE or downstream
router, the delegating router will not send unsolicited RA for the
allocated prefix pool.

Also, all of this effort is not to replicate the DHCPv6 behavior inside
RS/RA.  It's only to fill small gaps.

Please let me know your thoughts on these.

Yours,
Naveen.

On Wed, 21 Nov 2018 at 01:31, Brian E Carpenter <[email-masked]>
wrote:

> >>>>>>> a *new option* to go along with an already existing protocol
> (namely,
> >>>>>> DHCPv6).
> >>>>>> protocols.  I see that SLAAC has got some gaps w.r.t the
> functionality
> >>>> and
> >>>>>> wrong in quoting that both DHCPv6 and SLAAC are redundant protocols
> to
> >>>> each
> >>>>>> other?
> >>>>>>>
> >>>>>> suggested.  But not sure why they couldn't become standards.  It
> shows
> >>>> the
> >>>>>>>>> Cc: v6ops list <[email-masked]<mailto:[email-masked]>>; 6man WG
> <
> >>>>>> [email-masked]<mailto:[email-masked]>>
> >>>>>>>>>>>>>>>> So I can understand this comment, the water under the
> bridge
> >>>>>> refers to the
> >>>>>>>>>>>>>> OK, so you are saying that DHCPv6 is *the* chosen protocol
> for
> >>>>>> Prefix Delegation
> >>>>>>>>>>>>>> mind a statement like that, but would the community agree
> with
> >>>> it?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> By "different wrapping", are you are talking about
> non-DHCPv6
> >>>>>> protocol proposals?
> >>>>>>>>>>>>>> If not, if you mean to say that the idea of including a
> DHCPv6
> >>>>>> option in RS/RA messages
> >>>>>>>>>> a single channel access is less prone to collisions than
> requiring
> >>>>>> multiple
> >>>>>>>>>> channel accesses.
> >>>>>>>>>>
> >>>>>>>>>> channel contention multiple times. (That is not to say that
> common
> >>>>>> data
> >>>>>>>>>>>>> Different wrapping. As in exactly same protocol semantics,
> just
> >>>>>> options in ND instead of DHCP.
> >>>>>>>>>>>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 11:19:59 +0100 (CET)

On Tue, 20 Nov 2018, Templin (US), Fred L wrote:

> publicly-available DHCPv6 implementations that support prefix delegation 
> today. And, to instrument RS/RA to perform prefix delegation under a new 
> protocol would require a non-trivial amount of new code. So, why not 
> just use DHCPv6?

If you want to revoke the prefix delegated, both code bases would have to 
be enhanced since there is basically no implementation of DHCPv6 
reconfigure.

So this proposal has that "built in" (zero lifetime) the same way we do 
everything else in ND, whereas DHCPv6 would need extra code for this not 
currently existing.

Taking one step back, what I would like (and I have said this before) is 
to get rid of the need for DHCPv6, and do everything in ND/RA. I'm ok with 
taking the entire DHCPv6 stateless option space and just following that 
registry of options and contents, but then take the stateful part of 
DHCPv6 and put it into ND as something "new". Perhaps copy part of the 
state machine from DHCPv6 if that makes sense.

My main reason for this is lack of dhcp-reconfigure in todays 
implementations, but also the fact that I do not like ships in the 
night-approach between DHCPv6 and ND/RA. From what I know, we do not have 
a document that states what a device should do with its PD when it 
receives a zero lifetime RA from something that also happens to be its 
DHCPv6 relay/server. RFC7084 gives some advice, but that's not applicable 
to a host running VMs that it delegates addresses to (could be, but the 
document isn't aimed at that kind of device).

That's the problem I think a proposal along the lines of 
slaac-prefix-management strategy has benefit.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Nov 2018 12:02:01 +0100

Naveen,

> Refined my problem statements below.  Please let me know if this is okay.

I am sorry, but I am still not able to see anything that you cannot do with the existing solutions for prefix delegation.
If the tradeoff here is for you to spend 2-3 days writing a DHCPv6 PD implementation, or spending the time of hundreds of people on this list for months to come… you have chosen the latter. That doesn’t seem like a fair tradeoff to me.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Nov 2018 14:45:55 +0100

Le 21/11/2018 à 12:02, Ole Troan a écrit :
> I am sorry, but I am still not able to see anything that you cannot 
> do with the existing solutions for prefix delegation.

On some embedded platform, a DHCP server that gives a prefix with 
DHCP-PD can't also give a default route.

OpenWRT's odhcpd deprecates radvd, implements DHCPv6-PD and SLAAC, yet 
cant set the router lifetime in RA (be a defrouter).

> If the tradeoff here is for you to spend 2-3 days writing a DHCPv6 PD
> implementation,

The question is what is worth spending time on writing code:
- add default route in DHCPv6?
- kill odhcpd and come back to radvd enhanced with draft-naveen?
- improve odhcpd to set lifetime and thus give default route?

Alex

> or spending the time of hundreds of people on this
> list for months to come… you have chosen the latter. That doesn’t
> seem like a fair tradeoff to me.
> 
> Cheers, Ole
> 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Nov 2018 14:55:08 +0100

Le 18/11/2018 à 19:16, Ole Troan a écrit :
> Naveen,
> 
> I don’t understand the problem description below, nor why it would 
> require a different solution than any of those we already have.

For my part, I think the problem is important in that we do not have a 
solution at this time.

We do not have a solution of simultaneous Prefix Delegation and Default 
Route that is widely available on many platforms from small to large.

What one may have running ok Prefix Delegation (DHCPv6 Server) and 
Default Route (ICMPv6 Router Advertisement daemon) is a PC that is able 
to run huge software on its powerful Intel processor over Ethernet at 1GBps.

Alex

> On 18 Nov 2018, at 18:51, Naveen Kottapalli <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> Hello Ole,
>>
>> On Sat, 17 Nov 2018, 23:05 Ole Troan <[email-masked] 
>> <mailto:[email-masked]> wrote:
>>
>>     Hi Naveen,
>>
>> 1. Solicit any prefix of pre configured length using RS / RA. We can 
>> have it implemented in both of our CPE and router. But the solution 
>> wouldn't be compliant or interoperable.
>> lingering though the host interface is brought down and the prefix 
>> isn't used anymore.
>> 3. Hosts during mobility are losing the existing ongoing traffic 
>> sessions due to prefix change. This is because when the gateway 
>> detects mobility to a different tunnel the existing session will be 
>> cleared and a new session entry is created. During this process there 
>> is no guarantee that the same prefix will be assigned back to the device.
>>
>>
>> solution till date to solicit or release a specific prefix. It's not 
>> just specific prefix, but the only existing solution to get a non /64 
>> prefix is only through DHCPv6, which can't be done in the CPE.
>>
>>
>> Naveen] Unfortunately yes for the use case where prefix length less 
>> than 64. I see this as more like soliciting a prefix pool.  All the 
>> host / CPE does is soliciting a prefix of desired length by including 
>> existing options in RS.  But why a host or CPE soliciting a prefix 
>> (which is already done by them) without introducing new message types 
>> or options should be a problem?
>>
>>
>>     Cheers
>>     Ole
>>
>>     On 17 Nov 2018, at 18:16, Naveen Kottapalli
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>     Hello Ole,
>>>
>>>     2. Improving SLAAC as a protocol by providing options like
>>>     soliciting a prefix of certain length; releasing or declining a
>>>     prefix (this is equally more important for the protocol
>>>     perspective itself as a prefix is an important resource for the
>>>     router).
>>>
>>>     On Fri, 16 Nov 2018, 00:21 Ole Troan <[email-masked]
>>>     <mailto:[email-masked]> wrote:
>>>
>>>         Naveen,
>>>
>>>         > On 15 Nov 2018, at 18:17, Naveen Kottapalli
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>         >
>>>         > Hello all,
>>>         >
>>>         > To be honest, there is no intention to compete with other
>>>         existing protocols.  I see that SLAAC has got some gaps w.r.t
>>>         the functionality and the same is covered in the draft.  And
>>>         I see the cases where this draft solves real time problems
>>>         where the existing bridge itself is not usable.
>>>         >
>>>         > @Ole / @Fred / others: If a device soliciting something
>>>         from the router using RS is considered as intruding into
>>>         other territory, IMHO it's very unfair way of evaluating. 
>>>         For that matter whether a PIO is included in RS or not, a
>>>         device is soliciting the information from router.  When this
>>>         draft solves the problems it cannot be put down just by
>>>         saying it as a redundant to another standard, while actually
>>>         it is not.
>>>         >
>>>         > If a device soliciting required information using the
>>>         existing protocol standards without new message types or
>>>         option types or flags itself is treated as a wrapper or
>>>         redundant for other standards, aren't there overlapping
>>>         options in both SLAAC and DHCPv6 that can be sent to the
>>>         devices?  For that matter what about the complete SLAAC and
>>>         DHCPv6?  Am I wrong in quoting that both DHCPv6 and SLAAC are
>>>         redundant protocols to each other?
>>>         >
>>>         > I also agree that multiple attempts were made by many
>>>         respected members of the forum to bring in similar changes to
>>>         whatever my current draft suggested.  But not sure why they
>>>         couldn't become standards.  It shows the need of devices that
>>>         are looking for a solution and am sure people keep inventing
>>>         round-about solutions for the same.
>>>         >
>>>         > If someone sees a problem in mentioning DHCPv6 inside the
>>>         draft, please suggest another change for that.
>>>         >
>>>         > I understand that the forum has finite reservations on
>>>         providing extensions to existing protocols.  But I request
>>>         the forum and WG chairs to evaluate this draft fairly and
>>>         technically.
>>>         >
>>>         > Yours,
>>>         > Naveen.
>>>         >
>>>         >
>>>         > On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>         > in line..
>>>         <mailto:[email-masked]>]
>>>         > >> To: Templin (US), Fred L <[email-masked]
>>>         <mailto:[email-masked]>>; Ole Troan
>>>         <[email-masked] <mailto:[email-masked]>>
>>>         > >> Cc: v6ops list <[email-masked] <mailto:[email-masked]>>;
>>>         6man WG <[email-masked] <mailto:[email-masked]>>
>>>         > >>>> Cc: Naveen Kottapalli <[email-masked]
>>>         <mailto:[email-masked]>>; 6man WG <[email-masked]
>>>         <mailto:[email-masked]>>; v6ops list <[email-masked]
>>>         <mailto:[email-masked]>>
>>>         > >>>>> On 13 Nov 2018, at 19:25, Templin (US), Fred L
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>         > >>>>>
>>>         > >>>>> Ole,
>>>         > >>>>>
>>>         > >>>>>> Cc: Naveen Kottapalli <[email-masked]
>>>         <mailto:[email-masked]>>; 6man WG <[email-masked]
>>>         <mailto:[email-masked]>>; v6ops list <[email-masked]
>>>         <mailto:[email-masked]>>
>>>         > >>>>>>> On 13 Nov 2018, at 17:34, Templin (US), Fred L
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>         > >>>>>>>
>>>         > >>>>>>> Hi Ole,
>>>         > >>>>>>>
>>>         > >>>>>>>> To: Templin (US), Fred L
>>>         <[email-masked] <mailto:[email-masked]>>
>>>         > >>>>>>>> Cc: Naveen Kottapalli <[email-masked]
>>>         <mailto:[email-masked]>>; 6man WG <[email-masked]
>>>         <mailto:[email-masked]>>; v6ops list <[email-masked]
>>>         <mailto:[email-masked]>>
>>>         > >>>>>>>>>>> I agree to some extent that DHCPv6 is a format
>>>         on wire.  But am sure it would consume more resources at
>>>         router to
>>>         > >> support
>>>         > >>>>>>>> DHCPv6
>>>         > >>>>>> In general we as a community try to avoid providing
>>>         multiple equivalent solutions to the same problem. Sometimes
>>>         we fail.
>>>         > >>>>>
>>>         > intentionally competes with DHCPv6-PD, which is a different
>>>         discussiion..
>>>         >
>>>         >     Brian
>>>         >
>>>         > >
>>>         > > Thanks - Fred
>>>         > >
>>>         > >> https://tools.ietf..org/html/rfc7788#section-6.3.4
>>>         <https://tools.ietf.org/html/rfc7788#section-6.3.4>
>>>         > >>
>>>         > >>    Brian
>>>         > >>
>>>         > >>>
>>>         > >>>>>>>> The value proposition of something new, has to be
>>>         different than “just different wrapping”.
>>>         > >>>>>>>
>>>         non-DHCPv6 protocol proposals?
>>>         > >>>>>>> If not, if you mean to say that the idea of
>>>         including a DHCPv6 option in RS/RA messages
>>>         > >>>>>>> is "just a different wrapping", then that is not
>>>         entirely true. By including both the IPv6
>>>         > >>>>>> Don’t really see that as interesting. You will not
>>>         save a round trip, since the two protocols don’t depend on
>>>         each other.
>>>         > >>>>>
>>>         > >>>>>> Different wrapping. As in exactly same protocol
>>>         semantics, just options in ND instead of DHCP.
>>>         > >>>>>
>>>         > >>>> Right. I am sorry but I struggle getting why that is
>>>         valuable. ND is also a one to many protocol. That’s not
>>>         suitable for per-router
>>>         > >>>> delegation.
>>>         > >>>
>>>         > >>>>>>>> We are still struggling with “permissionless
>>>         extensions” of an IPv6 network. Something that solved that
>>>         problem, would be a
>>>         > >> lot
>>>         > >>>>>> more
>>>         > >>> [email-masked] <mailto:[email-masked]>
>>>         > [email-masked] <mailto:[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Nov 2018 15:24:48 +0100

Alexandre,

> For my part, I think the problem is important in that we do not have a solution at this time.
> 
> We do not have a solution of simultaneous Prefix Delegation and Default Route that is widely available on many platforms from small to large.

And you are proposing a new solution that is available on exactly zero platforms?

> What one may have running ok Prefix Delegation (DHCPv6 Server) and Default Route (ICMPv6 Router Advertisement daemon) is a PC that is able to run huge software on its powerful Intel processor over Ethernet at 1GBps.

Both router discovery and PD can be done in a single packet exchange.
As they are independent of each other, practically it’s done in a single RTT.
How slow a link are you talking about?
A 10kbps link does about 14 packets per second. So even on that you would manage to do RS/RA and SOLICIT/REPLY in about 1/2th of a second. (Doing a little bit of a guess on packet sizes).

Executive summary: Your claims are not reality checked.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Nov 2018 15:58:02 +0100

Le 21/11/2018 à 15:24, Ole Troan a écrit :
> Alexandre,
> 
>>> I don’t understand the problem description below, nor why it
>>> would require a different solution than any of those we already
>>> have.
>> 
>> We do not have a solution of simultaneous Prefix Delegation and
>> Default Route that is widely available on many platforms from small
>> to large.
> 

Rather I support all proposal towards conceptual unification of the two 
protocols.  Once that is agreed it will lead to common implementation 
(improve odhcp to also do defrouter, or improve radvd to also do PD, etc.)

Other than this PD-defrouter problem there is other dimension but 
similar double software problem related to RS/RA waiting to happen: 
RFC4191 more specific routes receiver present both in linux kernel and 
in userspace (odhcpd) - which one prevails?

Until that unification is done we keep seeing such problems of double 
messages, double protocols, double implementations, double skillset.

>> Default Route (ICMPv6 Router Advertisement daemon) is a PC that is
>> able to run huge software on its powerful Intel processor over
>> Ethernet at 1GBps.
> 

1. in current state of protocols it is impossible to do PD and router 
discovery in a single packet exchange.  One needs at least an RS/RA (two 
packets) for router discovery and at least an Req/Response (two other 
packets) for DHCPv6 PRefix Delegation.

2. it is not the entire Router Discovery that is a problem that I see. 
The problem is in more detail in just the RA of the software 
implementation that does also DHCPv6-PD.

So I do not agree almost at all with your statement that "Both router 
discovery and PD can be done in a single packet exchange", and I do not 
see why do you say it.

Do you know of a software implementation that runs on embedded platform 
openWRT that does both DHCPv6-PD _and_ RA Default Route and does not use 
two software packages?

If you do _not_ know, do you think that it is not a problem that there 
are two software packages for PD+defroute?

> As they are independent of each other, practically it’s

No, this is a wrong statement.  Currently RS/RA and DHCP are not in a 
single RTT.

> How slow a link are you talking about? A 10kbps
> link does about 14 packets per second. So even on that you would
> manage to do RS/RA and SOLICIT/REPLY in about 1/2th of a second.
> (Doing a little bit of a guess on packet sizes).

There are many degrees in using terms 'slow'.  What Fred mentions as air 
links I see as a limit, but there are many degrees up to that limit 
where the problem is still valid.

When I write about embedded platforms being limited I mean all these 
hardware platforms, _and_ communication links, that range from Ethernet 
10GBps and 8GHz clock 32Gb RAM down to Lora and 32kb RAM.

In most of these intermediary platforms there is a problem of putting 
_two_ software packages like SLAAC and DHCP implementations.

Most of these, if not all, need defroute _and_ prefix delegation.

> Executive summary: Your claims are not reality checked.

I gave earlier a precise example of openwrt.

It is _way_ too much software to run both odhcpd _and_ radvd, while also 
pretending that radvd is deprecated.

It is not only too much in terms of RAM needed by these software 
packages, but too much also in terms of skills needed by the sysadmin or 
the student, documentation, config files, and more.

I do not understand how one does not see this as being a problem.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 15:09:06 +0000

Mikael,

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2018 2:20 AM
> Cc: Naveen Kottapalli <[email-masked]>; Brian E Carpenter <[email-masked]>; 6man WG <[email-masked]>;
> v6ops list <[email-masked]>

Any DHCPv6 Reconfigure service would be conducted through RS/RA the
same as any of the other DHCPv6 primitives.

> everything else in ND, whereas DHCPv6 would need extra code for this not

I can't understand from this what you are talking about. The DHCPv6-ND
approach inherits all of IPv6ND - not only just the features of DHCPv6.

> state machine from DHCPv6 if that makes sense.

I don’t understand this either. Anything new that would be brought into
IPv6ND would simply be re-creating what DHCPv6 already does.

> night-approach between DHCPv6 and ND/RA.

That is why 'draft-templin-6man-dhcpv6-ndopt' advocates a
unified service of DHCPv6-ND.

> From what I know, we do not have

A unified DHCPv6-ND service also addresses this. And, with protocols
that are well known and widely implemented.

Thanks - Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 15:22:59 +0000

Hi Alex,

We have implemented the DHCPv6-ND solution discussed in
'draft-templin-6man-dhcpv6-ndopt' . You get all of IPv6ND
and DHCPv6 in a single message exchange (or, two message
exchanges if you need to do 4-message DHCPv6). We did
this using OpenVPN as our development platform and with
unmodified kea DHCPv6 server.

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, November 21, 2018 5:46 AM
> To: [email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 15:27:06 +0000

HI Alex,

> Sent: Wednesday, November 21, 2018 5:55 AM
> To: [email-masked]

Our implementation of DHCPv6-ND is publicly available and runs on really
any platforms small to large. It is linux-based, and so can run anywhere
linux can run.

> to run huge software on its powerful Intel processor over Ethernet at 1GBps.

Powerful processers aren't needed - we run our code on Android cellphones, e.g.,

Thanks - Fred

> >>>         <mailto:[email-masked]>>
> >>>         <mailto:[email-masked]>>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 15:34:15 +0000

I agree with Alex that there is a need for doing everything in a single unified
exchange - fewer messages is fewer messages, which is very important for
low-end links of any variety (aviation or otherwise) and likewise beneficial
for any link regardless of bandwidth.

However, I do not see the problem of two software packages as being too
many. As I have stated in my documents, it would be nice if all functions
could be rolled up into a single software module, but a lightweight DHCPv6
relay agent function can be used if the RS/RA and DHCPv6 functions are in
different modules (we have coded this).

Thanks - Fred

> Sent: Wednesday, November 21, 2018 6:58 AM
> To: Ole Troan <[email-masked]>
> Cc: 6man WG <[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Nov 2018 16:37:07 +0100

> Rather I support all proposal towards conceptual unification of the two protocols.  Once that is agreed it will lead to common implementation (improve odhcp to also do defrouter, or improve radvd to also do PD, etc.)
> 
> Other than this PD-defrouter problem there is other dimension but similar double software problem related to RS/RA waiting to happen: RFC4191 more specific routes receiver present both in linux kernel and in userspace (odhcpd) - which one prevails?
> 
> Until that unification is done we keep seeing such problems of double messages, double protocols, double implementations, double skillset.

Don’t hold your breath.

> 1. in current state of protocols it is impossible to do PD and router discovery in a single packet exchange.  One needs at least an RS/RA (two packets) for router discovery and at least an Req/Response (two other packets) for DHCPv6 PRefix Delegation.
> 
> 2. it is not the entire Router Discovery that is a problem that I see. The problem is in more detail in just the RA of the software implementation that does also DHCPv6-PD.
> 
> So I do not agree almost at all with your statement that "Both router discovery and PD can be done in a single packet exchange", and I do not see why do you say it.

Each. Single packet exchange each.

> Do you know of a software implementation that runs on embedded platform openWRT that does both DHCPv6-PD _and_ RA Default Route and does not use two software packages?

Yes. VPP.

> If you do _not_ know, do you think that it is not a problem that there are two software packages for PD+defroute?

Even when I do know, I don’t think it’s a problem.
PD is a router to router protocol, RS/RA is a host to router. And you can perfectly well run PD without RS/RA.

> No, this is a wrong statement.  Currently RS/RA and DHCP are not in a single RTT.

“Practically single RTT”. You send the SOLICIT and RS back to back.

> There are many degrees in using terms 'slow'.  What Fred mentions as air links I see as a limit, but there are many degrees up to that limit where the problem is still valid.
> 
> When I write about embedded platforms being limited I mean all these hardware platforms, _and_ communication links, that range from Ethernet 10GBps and 8GHz clock 32Gb RAM down to Lora and 32kb RAM.
> 
> In most of these intermediary platforms there is a problem of putting _two_ software packages like SLAAC and DHCP implementations.
> 

Nothing forcing you to implement this as separate packages. As if that matters very much.
VPP has it as a single package. The real small stuff tend to use protocols developed in 6lo et al.

> I gave earlier a precise example of openwrt.

There is other running code where this does not apply.
Your argument of using a particular implementation choice to set direction for standarisation is dubious.

> It is _way_ too much software to run both odhcpd _and_ radvd, while also pretending that radvd is deprecated.
> 
> It is not only too much in terms of RAM needed by these software packages, but too much also in terms of skills needed by the sysadmin or the student, documentation, config files, and more.
> 

Neither do we understand you seeing it as a problem. ;-)

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 17:11:36 +0100 (CET)

> approach inherits all of IPv6ND - not only just the features of DHCPv6.

The subject is about draft-naveen-slaac-prefix-management which is what I 
am commenting on. I am not commenting on your document. I do not like the 
idea to tunnel DHCPv6 messages unchanged in ND/RA.

> IPv6ND would simply be re-creating what DHCPv6 already does.

Yes.

> That is why 'draft-templin-6man-dhcpv6-ndopt' advocates a unified 
> service of DHCPv6-ND.

Ok.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 16:15:15 +0000

Hi Mikael,

> Sent: Wednesday, November 21, 2018 8:12 AM

Sorry you don’t like the idea, but please don’t call it "tunneling" because
that is not what DHCPv6ND is about. It is about a unified service that
combines the best elements of the two services.

> > IPv6ND would simply be re-creating what DHCPv6 already does.

Good. Then we stick with DHCPv6.

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 17:36:01 +0100 (CET)

> combines the best elements of the two services.

"RS message containing a DHCPv6 option that embeds a DHCPv6 Solicit 
message."

When I read the rest of 
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-06#section-2.2 
I read "embed" which for me is pretty much the same as "tunnel". All of 
2.2 is basically just wrapping/embedding/tunneling DHCPv6 messages in 
RS/RA messages.

Or what am I missing?

My opposition to DHCPv6 stateful here is "do we actually need everything 
that DHCPv6 does to solve our problem"? And also, do we actually want to 
do it exactly the same as DHCPv6 does it? For instance, do we want DHCPv6 
reconfigure when we instead can just send messages with 0 lifetime and 
have that mean the same thing?

>From reading your proposal, you do not say "let's just use function X, Y 
and Z of DHCPv6 and not the rest" but instead you just say "let's embed 
any DHCPv6 message and that should be supported".

There are multiple aspects of DHCPv6 that I do not like and wouldn't want 
to go into a solution you're describing. The whole relay concept in 
conjunction with PD is just not specified *at all* in any IETF document I 
know of. I've had plenty of implementation problems based on this where 
relays just did the wrong thing. I do not want to bring with us all the 
legacy that DHCPv6 has and things that are not defined.

> Good. Then we stick with DHCPv6.

Please do not put words in my mouth.

---

From: Ole Troan <[email-masked]>
Date: Wed, 21 Nov 2018 18:03:24 +0100

> My opposition to DHCPv6 stateful here is "do we actually need everything that DHCPv6 does to solve our problem"? And also, do we actually want to do it exactly the same as DHCPv6 does it? For instance, do we want DHCPv6 reconfigure when we instead can just send messages with 0 lifetime and have that mean the same thing?

As soon as you think about the security issues, then you’d end up with something very similar to DHCP reconfigure.
You need state to be able to “reconfigure”.

> and Z of DHCPv6 and not the rest" but instead you just say "let's embed any DHCPv6 message and that should be supported".
> 
> There are multiple aspects of DHCPv6 that I do not like and wouldn't want to go into a solution you're describing. The whole relay concept in conjunction with PD is just not specified *at all* in any IETF document I know of. I've had plenty of implementation problems based on this where relays just did the wrong thing. I do not want to bring with us all the legacy that DHCPv6 has and things that are not defined.

The relay is not specified for a reason. You don’t need to use it.
The same issue applies to any other solution, if you need some sort of relaying.

I would be much more supportive of these efforts if they focused on solving some of the issues that DHCPv6 PD does not deal well with.

- route injection
- renumbering / reconfiguration
- multiple sources
- arbitrary topologies

But as long as the idea is to gloss over the hard problems, and replicate DHCPv6 protocol mechanics in ND, it’s hard to get very excited.
It’s quite likely that any effort in this space is going to look an awfully much like HNCP.

Ole

---

From: Naveen Kottapalli <[email-masked]>
Date: Wed, 21 Nov 2018 22:59:44 +0530

Fred,

Being a new entrant in the forum with my draft, I will always be grateful
and acknowledge all the contributions.  In fact when I shared the draft
with your for review before submission, I sent to other senior members of
the forum.  For that matter @Ole, @Brian and whoever contributes their
names will be mentioned in upcoming version of my draft.

The reason why the advice of a similar thing to DHCPv6 DUID not taken was,
there is a fundamental difference between your draft and mine.  Your draft
proposes an unified approach of using DHCPv6 inside RS/RA, whereas my draft
says things can be done without DHCPv6 and any other new options or flags
too.

As you suggested me to cite, 'draft-templin-v6ops-pdhost' was cited in
respective places of my draft.  I don't know how more to acknowledge your
inputs in my draft.  If you feel that you are not acknowledged well, please
let me know what citation changes I can do in my draft to make you happy.

Finally, I would like to use this forum to improvise the draft more
technically.  You can directly message me.

Yours,
Naveen.

On Wed, 21 Nov 2018 at 20:18, Templin (US), Fred L <
[email-masked]> wrote:

> Hi Naveen,
>
>
>
> Also the idea of including a PIO in an RS message was originally mine as
> documented
>
> in my draft. Others may claim that they brought up the idea first, in
> which case I
>
> would be happy to honor their drafts. Your contribution was to not include
> any
>
> special bits in the RS PIO, which I agree is a good contribution. But, in
> hindsight,
>
> the idea should have been offered as a contribution to my draft even if
> the new
>
> protocol were to be documented in a separate draft.
>
>
>
> Also, I told you that you need to say something about node identifiers that
>
> parallels the DHCPv6 DUID for client and server IDs. You did not take my
>
> advice, and so that is a missing aspect of your proposal. The only
> candidate
>
> I am aware of for RS/RA is the SLLAO option, but that only gives link-layer
>
> address, and not any of the other type of identifiers offered by DHCPv6.
>
>
>
> Finally, your use case is already covered by ‘draft-templin-v6ops-pdhost’,
>
> which shows that DHCPv6 is applicable for the needs. If you think there
>
> is something different about your use case, that would be useful input
>
> for ‘draft-templin-v6ops-pdhost’ – but not material for a new draft.
>
> In any case, your document needs to cite ‘draft-templin-v6ops-pdhost’.
>
>
>
> Thanks - Fred
>
>
>
> *Sent:* Tuesday, November 20, 2018 6:12 PM
> *To:* Templin (US), Fred L <[email-masked]>
> *Cc:* Brian E Carpenter <[email-masked]>; Ole Troan <
> >> discussiion.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Nov 2018 18:39:23 +0100

> any platforms small to large. It is linux-based, and so can run anywhere

In theory yes, and I am wondering whether there is a package of 
DHCVPv6-ND for openwrt?  I am not able to build packages, and on small 
openwrt platforms it is almost impossible to compile natively.

And also, before I plan into using it, I wont commit any effort if it's 
not a standard.

Yes.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 17:46:35 +0000

Hi Mikael,

> Sent: Wednesday, November 21, 2018 8:36 AM

It is an IPv6ND option like any other - we do not call PIOs, RIOs, etc.
MTU options, etc. "tunneling".

> have that mean the same thing?

Do you have just one or a few use cases in mind when you say "solve our
problem"? What I am suggesting is a general purpose solution that solves
our problems, which is more or less picked up for free based on all of
the existing code.

> any DHCPv6 message and that should be supported".

Why would we throw out functions that we might need in the future
if the code is already there?

> know of.

That is interesting, because DHCPv6 relay (in particular, RFC6221 Lightweight
DHCP Relay Agent) is at the heart of my implementation and works well.

>I've had plenty of implementation problems based on this where

I don't know what you are referring to - our relay implementation
works as it should.

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 19:06:49 +0100 (CET)

> our problems, which is more or less picked up for free based on all of 

See what Ole posted a few emails previous to this.

Some examples:

What does it mean when you have an IA_NA with 24 hours lease time and the 
encompassing /64 PIO just arrived with zero lifetime? What does that 
actually mean? What should the host do? Where is this documented?

If you said you would take a lot of DHCP but fix these kinds of problems 
by ripping out the lease timers or defining exactly what they mean in ND 
context then I'd be a lot more supportive. But then it wouldn't be DHCPv6 
anymore.

> DHCP Relay Agent) is at the heart of my implementation and works well.

The words "route" and "IA_PD" give zero hits in that document. So if 
you're using IA_PD then I guess you're doing things outside of what that 
document specifies?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 19:09:02 +0100 (CET)

> It’s quite likely that any effort in this space is going to look an awfully much like HNCP.

I agree 100%, and that's why I'm opposing the efforts until they try to 
solve at least some of these problems.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 18:18:12 +0000

Hi Mikael,

> Sent: Wednesday, November 21, 2018 10:07 AM

That particular example does not relate specifically to the DHCPv6-ND proposal;
the proposal is not out to solve interactions between SLAAC and DHCPv6, but
in this particular example common sense should prevail.

> you're using IA_PD then I guess you're doing things outside of what that

The LDRA is a DHCPv6 relay agent like any other. The behavior of DHCPv6
relay agents wrt prefix delegation is covered in RFC3633, Section 14.

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Nov 2018 19:23:25 +0100 (CET)

On Wed, 21 Nov 2018, Templin (US), Fred L wrote:

> That particular example does not relate specifically to the DHCPv6-ND 
> proposal; the proposal is not out to solve interactions between SLAAC 
> and DHCPv6, but in this particular example common sense should prevail.

I know, and that's why I don't like it. I want this problem solved, not 
glossed over.

> relay agents wrt prefix delegation is covered in RFC3633, Section 14.

Errr, it's "covered" in the fact that it doesn't say how to do that.

"If a delegating router communicates with a requesting router through
    a relay agent, the delegating router may need a protocol or other
    out-of-band communication to add routing information for delegated
    prefixes into the provider edge router."

It doesn't say "inspect the relayed message and guess that you might need 
to install a route and keep state for that route". How do you do this?

I have seen several relay implementations that relayed the message just 
fine but didn't install any route, leaving the PD useless for the end 
user.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 18:40:47 +0000

Hi Mikael,

> Sent: Wednesday, November 21, 2018 10:23 AM

In a case that I care about, the delegating router and relay agent are on
one and the same platform. So, the delegating router does just what the
spec says, and the relay agent's needs are satisfied. Maybe Ole can say
more about what is expected when the delegating router and relay
agent are on different platforms.

Fred

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Nov 2018 14:33:45 -0500

Mikael Abrahamsson <[email-masked]> wrote:
    > encompassing /64 PIO just arrived with zero lifetime? What does that actually
    > mean? What should the host do? Where is this documented?

    > If you said you would take a lot of DHCP but fix these kinds of problems by
    > ripping out the lease timers or defining exactly what they mean in ND context
    > then I'd be a lot more supportive. But then it wouldn't be DHCPv6 anymore.

Here is a different, but related question to put this in perspective:

If the IA_NA or IA_PD has a non-trivial lifetime, but it's on a PPPoE
connection (or a LTE/3G link, I guess), and the (PPPoE) link dies, what
do you expect when it returns?   Basically, the outer "times" kill the
inside timers, and really everything works.

What I'm actually saying is that DHCPv6 already deals with this problem.
I would be rather more happy to see PD done inside unicast ND messages,
and I don't much mind if it's done by being able to carry DHCPv6 format
options.

(The PPP guys are still regretting not doing exactly that for DHCPv4 vs
IPCP.)

[ps: not much of a fan of PPPoE, even though I've spent ~5 years
implementing.  It does provide for a useful way to do
Third-Party-Internet-Access over ethernet-like technologies, and the
resulting competition is good for the Internet.  I just wish we were using
PPP to negotiate an MPLS or SegmentRouting tag that could statelessly,
and trivially be processed in hardware....]

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2018 08:52:03 +1300

On 2018-11-22 03:56, Templin (US), Fred L wrote:
> I think any prefix delegation service needs to allow for any legitimate prefix
> length of /64 or shorter. 

Or longer. Routing prefixes in IPv6 can be any length up to /128.
Without regard to the whole "Why /64?" debate, we must ensure that
all prefix mechanisms are agnostic on the actual prefix length.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2018 08:58:50 +1300

> agent are on different platforms.

Since DHCPv6 is a separate entity from any routing protocol, this
is a case where inside a single box they could be linked by a privately
defined API but in different boxes they would need a protocol, which
could of course be either proprietary or standardised. What's new
here?

    Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 21 Nov 2018 20:19:59 +0000

> Maybe Ole can say

Well, not Ole ...

And, as relay agents are typically also the routers and they see the DHCPv6 packets already, they just snoop the inside to find the client message and do what's needed for the PD and to advertise the prefixes. At least, that's what happens for DOCSIS on the CMTS.

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Wednesday, November 21, 2018 2:59 PM
To: Templin (US), Fred L <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Cc: v6ops list <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

    Brian

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 21 Nov 2018 21:33:27 +0000

Hi Brian,

> Sent: Wednesday, November 21, 2018 11:59 AM
> defined API

What I am using is the standard linux "ip" command, as in:

  # ip route add <foo>
  # ip route del <foo>
  etc.

> but in different boxes they would need a protocol, which
> could of course be either proprietary or standardised.

Bernie contributed the point about relay agents gleaning route
info from the DHCPv6 messages they forward. Actually, that is
also what my LDRA code does, even though everything is all
together in the same box.

> What's new here?

Nothing - but, that is a good thing.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2018 10:45:19 +1300

> What I am using is the standard linux "ip" command, as in:

And wouldn't life be better if the IETF didn't have an aversion
to defining APIs, so that you could do that in an O/S independent
way?

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Nov 2018 23:00:49 -0300

> to defining APIs, so that you could do that in an O/S independent

IN fact, we do specify APIs.. although sometimes way to late, are when
is has become way too evident (and/or when it has become way too late)
that we need to.

e.g.... we do have all these IPv6 addresses of different sorts but...
try to use them in any meaningful way and it should become clear that
protocol features without an appropriate API is likely to lead to
protocol *failures*.

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

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 22 Nov 2018 08:06:36 +0530

Hello,

Is there a case where a CPE would require a prefix > 64 bit?

Thanks & Regards,
Naveen

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 22 Nov 2018 08:39:52 +0530

In our gateway too DHCPv6 is a separate entity for assigning IA_NAs to
devices, which is connected to the routing entity with a private or
unstandardized API.  Is there a scope for standardizing such API?

On Thu, 22 Nov 2018, 01:28 Brian E Carpenter <[email-masked]
wrote:

> >> Cc: Naveen Kottapalli <[email-masked]>; Brian E Carpenter <
> [email-masked]>; 6man WG <[email-masked]>;
> >> Subject: RE: [v6ops] New Version Notification for

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2018 17:37:03 +1300

Naveen,

> Is there a case where a CPE would require a prefix > 64 bit?

That isn't our business when designing a general prefix delegation
mechanism. The architecture is clear; please see RFC7608 (BCP198)
for background.

As long as the prefix length for SLAAC is defined as /64, that
is the longest we will see, but who knows what it will be 50 years
from now?

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 22 Nov 2018 06:18:28 +0100 (CET)

> together in the same box.

I know this is what they do, but there is no document defining how to do 
it.

I have lots of operational scars from this not working, and when the 
largest vendors with their "best in class" operating system implementers 
can't get it right, who can?

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Nov 2018 13:40:20 +0100

Le 21/11/2018 à 16:37, Ole Troan a écrit :
[...]
>> Do you know of a software implementation that runs on embedded 
>> platform openWRT that does both DHCPv6-PD _and_ RA Default Route 
>> and does not use two software packages?
> 
> Yes. VPP.

Thank you for this pointer.  It stands for Vector something.

>> If you do _not_ know, do you think that it is not a problem that 
>> there are two software packages for PD+defroute?
> 
> Even when I do know, I don’t think it’s a problem. PD is a router to
>  router protocol, RS/RA is a host to router. And you can perfectly 
> well run PD without RS/RA.

This is a very important point.

The way in which you qualify it makes think you have a particular idea
about what is a router, and that gives a clear idea to you.

However, there are circumstances where this assumed definition of a
Router (or of a Host for that matter), may get out of the frame you
may have set.

In these circumstances, it would be appropriate either to discard their
existence (say 'that's not a Router'), or try to update the existing
specs of what routers do.

As one example, this case of DHCPv6-PD and Default Route is a perfect
exponent of circumstance where your assumptions do not apply purely: my
home CPE needs both a Default Route with RA (so, byr current RFCs it's a 
Host, not a Router), and a delegated prefix with DHCPv6-PD (so it's a 
Router, not a Host).

Other examples abound, out of which allow me to go further and cite 
RFC4191 "More Specific Routes" - that spec is only for Hosts, but there 
are routers in cars doing car-to-car communications that need it for 
Routers too.

Yes.

> 
>>> How slow a link are you talking about? A 10kbps link does about 
>>> 14 packets per second. So even on that you would manage to do 
>>> RS/RA and SOLICIT/REPLY in about 1/2th of a second. (Doing a 
>>> little bit of a guess on packet sizes).
>> 
>> There are many degrees in using terms 'slow'.  What Fred mentions 
>> as air links I see as a limit, but there are many degrees up to 
>> that limit where the problem is still valid.
>> 
>> When I write about embedded platforms being limited I mean all 
>> these hardware platforms, _and_ communication links, that range 
>> from Ethernet 10GBps and 8GHz clock 32Gb RAM down to Lora and 32kb
>>  RAM.
>> 
>> In most of these intermediary platforms there is a problem of 
>> putting _two_ software packages like SLAAC and DHCP 
>> implementations.
>> 
> Nothing forcing you to implement this as separate packages. As if 
> that matters very much. VPP has it as a single package. The real 
> small stuff tend to use protocols developed in 6lo et al.

I will have to look at VPP in more detail.

Let me just add that small platforms and links is a larger domain
than what 6lo does.  And that 6lo is probably not answering many of the
other IP needs in these small platforms and links.

For example: if one wants the end-to-end principle of IP (node pings
google) then one wants IP in the small computer.  That would disqualify 
6lo's compression, or exact-match MAC forwarding, or lack of subnet 
structure, etc.

These small computers would however need IP default routes, delegated
prefixes, and acceptable forwarding speed (not necessarily ultra-high 
performance fast forwarding).

> There is other running code where this does not apply. Your argument
>  of using a particular implementation choice to set direction for 
> standarisation is dubious.

No.  With all due respect, it seems dubious to make standards based on 
what big Switches and Routers want.

Unless, of course, we state that the end-to-end principle happens only 
between big computers, and seggregate the small computers out.

> 
>> It is _way_ too much software to run both odhcpd _and_ radvd, while
>> also pretending that radvd is deprecated.
>> 
>> packages, but too much also in terms of skills needed by the 
>> sysadmin or the student, documentation, config files, and more.
>> 

We do not understand what in draft-naveen should we add to explain to you.

What small suggestion you have to us to add in the draft?

Alex

> cheers, Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Nov 2018 13:53:55 +0100

> What small suggestion you have to us to add in the draft?

I am making an assertion. The assertion is: if you specify Prefix Delegation within the ND protocol, it will when you are done look very much like DHCP PD.

Your only justifications for doing this seems to be: “I don’t want to implement DHCP”, or “DHCP takes too much space”.
Writing code is cheap, writing standards is expensive.

If I am correct then it is not justifiable to spend time standardizing a redundant specification.
(Also because that will force everyone else, to have to implementation of the same thing).

How can you convince me?
Write two implementations for your constrained device.
One with DHCP PD + ND and one with ND and ND PD.
Compare. Both implementations must be written specifically for this environment (don’t go pull packages from a Linux distro and claim that as a reason why it’s not a fit).

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Nov 2018 15:09:58 +0100

Le 23/11/2018 à 13:53, Ole Troan a écrit :
>>>> It is _way_ too much software to run both odhcpd _and_ radvd, 
>>>> while also pretending that radvd is deprecated. It is not only
>>>>  too much in terms of RAM needed by these software packages, 
>>>> but too much also in terms of skills needed by the sysadmin or 
>>>> the student, documentation, config files, and more. I do not 
>>>> understand how one does not see this as being a problem.
> I am making an assertion. The assertion is: if you specify Prefix 
> Delegation within the ND protocol, it will when you are done look 
> very much like DHCP PD.
> 
> Your only justifications for doing this seems to be: “I don’t want to
> implement DHCP”, or “DHCP takes too much space”.

No, we are beyond that point (quoting Fred).  This is not a religious
kind of argument against DHCP.  For my part I work commonly with DHCPv6
as with RA.  It's just it is cumbersome (both).

> Writing code is cheap, writing standards is expensive.

Right.  Writing new code is a cheap and thrilling way of getting rid of
maintaining code of existing standards.

> If I am correct then it is not justifiable to spend time 
> standardizing a redundant specification. (Also because that will 
> force everyone else, to have to implementation of the same thing).
> 
> How can you convince me? Write two implementations for your 
> constrained device. One with DHCP PD + ND and one with ND and ND PD.

This is a request that one can take into account.

Once that is done, do you want one to update the draft with some text?

Or are you assuming that the experiment will lead one to simply drop the
draft?

> Compare. Both implementations must be written specifically for this 
> environment (don’t go pull packages from a Linux distro and claim 
> that as a reason why it’s not a fit).

Hold on.  IT can be too much work to start from scratch; rather, pulling
packages is a true help.  odhcp6c is a good way because it implements
both DHCP-PD and RA.  But it has its own negative aspect in that it does
not do default route.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 24 Nov 2018 16:09:46 +0000

Hi Mikael,

> Sent: Wednesday, November 21, 2018 9:18 PM
> Cc: Brian E Carpenter <[email-masked]>; Naveen Kottapalli <[email-masked]>; 6man WG <[email-masked]>;

This subject came up on several different occasions on the dhc list. It
prompted the writing of "Relay Agent Assignment Notification (RAAN)":

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-agentopt-delegate/

Each time the document was brought back up for discussion, there was initial
interest followed by silence. Reason being is that people do not think it is a
problem, and that relay agents should just continue to glean from IA_PDs
as they have always done.

Do you think we should bring back RAAN?

Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 25 Nov 2018 07:15:23 +0100 (CET)

> Do you think we should bring back RAAN?

Yes, but also note that the relay behavior is my least concern with the 
DHCP+RA combination. The ships in the night problem between leasetimers 
(DHCP) and lifetimes (RA) is a much bigger concern for me.

---

From: Mark Smith <[email-masked]>
Date: Sun, 25 Nov 2018 18:45:17 +1100

> (DHCP) and lifetimes (RA) is a much bigger concern for me.

(I haven't followed this thread, apologies if it has been covered.)

In this scenario, I assume the DHCPv6 server is selecting the prefix
to delegate, and the BRAS is acting as a DHCPv6 relay, which is why
the BRAS has to glean the delegated prefix to then be able to announce
it into the routing domain? Are the delegated prefixes dynamic or
static, and if they're static (or at least stable across
disconnect/connect), is it correct that the CPE's DUID is being used
to re-issue the same delegated prefix?

The reason I ask is that the IPv6 residential broadband deployment I
worked on achieved this without gleaning via two methods:

- for static delegated prefixes, the prefix is supplied as part of the
RADIUS authentication response, which the BRAS DHCPv6 server then uses
for DHCPv6-PD, and the BRAS can then announce into the routing domain

- for dynamic delegated prefixes, the RADIUS server provided a pool
name to allocate from, with each BRAS having a local pool with that
name. At the time the pool name was a proprietary RADIUS attribute,
however there is now an IETF attribute for the pool name specified in
RFCRFC6911.

An alternative idea, although probably more medium term, would be to
have the CPE's receive the prefix via DHCPv6-PD, and then the CPE
advertises the prefix itself, using automatically established eBGP
sessions via a well known Link-Local anycast address.

"IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00

"5.7.3.  Automatic eBGP Session Establishment"
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00#section-5.7.3

Regards,
Mark.

---

From: Naveen Kottapalli <[email-masked]>
Date: Sun, 25 Nov 2018 22:14:22 +0530

Just adding my 2 cents.

Even in our gateway we have both SLAAC and DHCPv6.  For better routing of
subscriber traffic, though these are two different protocols we had to
assign a single prefix for each device.  In case of SLAAC we let the device
leverage the complete 128 bit address generation and in DHCPv6 case, our
box generates the 128 bit address using the same prefix, map against DUID
and sends back to the devices.  In the last 5-6 years of production till
now we have not seen any device requesting more than 1 IA_NA and even our
gateway does not support more than 1 DHCPv6 address; whereas all the
devices which got the SLAAC prefix used at most 16 addresses.

Yours,
Naveen.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2018 08:26:37 +1300

> devices which got the SLAAC prefix used at most 16 addresses.

How will all this work when the subscribers are homenets that need
/56 or /48 prefixes?

     Brian

---

From: Naveen Kottapalli <[email-masked]>
Date: Mon, 26 Nov 2018 15:01:55 +0530

Handling is different for that and work is in progress.

Yours,
Naveen.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 14:30:21 +0100

Le 25/11/2018 à 17:44, Naveen Kottapalli a écrit :
> Just adding my 2 cents.
> 
> Even in our gateway we have both SLAAC and DHCPv6.  For better routing 
> of subscriber traffic, though these are two different protocols we had 
> to assign a single prefix for each device.  In case of SLAAC we let the 
> device leverage the complete 128 bit address generation and in DHCPv6 
> case, our box generates the 128 bit address using the same prefix, map 
> against DUID and sends back to the devices.  In the last 5-6 years of 
> production till now we have not seen any device requesting more than 1 
> IA_NA

Funny.  You mean one home requests just one IA_NA?

Where I live, an ADSL operator gives a /56 to home (with an IPv4 tool). 
Then, there is GUI for grandma where she can select which /64 goes to 
which LL address inside home.

> and even our gateway does not support more than 1 DHCPv6 address; 
> whereas all the devices which got the SLAAC prefix used at most 16 
> addresses.

Dont put the fault on the end users.  End users do want to grow their 
edge networks, because they have more and more devices.  Listen to them 
to see what they need.

That (at most 16 addresses) is so because RFC4291 "IPv6 Addressing 
Architecture" has a huge problem that limits the growth of the network 
at the edge (in-house network).

That huge problem is the length of the Interface ID.  RFC4291 is read by 
most Consumers to mean that the IID length is 64.  That is also read by 
most Providers to mean that within one 64 there are plenty 2^64 
addresses.  Yet only one subnet can make this work, not two.  As 
paradoxical as it might seem, one cant have two subnets in house if all 
the operator gives is but one /64.

On another hand, if RFC4291 puts the IID variable length, and operator 
changes mind from fixed 64 prefixlen to a variable length too, then we 
can expect end users requesting much more than 16 addresses from one 
in-house network.

That's where Prefix Delegation operation is of high importance.

Alex

> 
> Yours,
> Naveen.
> 
> 
> On Sun, 25 Nov 2018 at 13:16, Mark Smith <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On Sun, 25 Nov 2018 at 17:16, Mikael Abrahamsson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     <mailto:[email-masked]..se>
>      >
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 29 Nov 2018 23:37:11 +0530

Yours,
Naveen.

On Wed, 28 Nov 2018 at 19:00, Alexandre Petrescu <
[email-masked]> wrote:

> Naveen] That is what we have seen in the last 5-6 years.
>
Naveen] I agree to what is said here.  But strangely none of the big cable
operators who are using the product live requested for support of more than
1 IA_NA or IA_TA.

> can expect end users requesting much more than 16 addresses from one
Naveen] Yes.  Since the current standards limit the end devices to use /64
only, it's working like that happily :)

> Naveen] Agree.
> >      > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >      >