Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Sep 2021 07:24:31 +0900

On Wed, 1 Sept 2021, 01:13 Michael Richardson, <[email-masked]>
wrote:

>     > It works if you're willing for routers to keep a lot of state and
> you have
>     > a reliable way to detect hosts that are no longer on link.
>
> Neighbor Cache Entries already exist, and are already indexed by node.
> You don't need more state than that.
>

Yes, but ND cache entries can be safely discarded because as soon as the IP
address is used again, the entry is re-created.

You cannot do this with RAs because if you stop sending RAs to a given
host, that host experiences an outage. So in a "unicast RA" scheme, the
router is forced to keep state for all on-link hosts at all times. Without
a reliable signal of when hosts go away, this doesn't scale and is subject
to DoS attacks.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Sep 2021 05:12:25 +0000

Hello Lorenzo

Since 1998 the memory available in the router grew with Moore’s Law. And we’re using it. Clearly you do not see the router side of the fence so please do not take it as your argument.

Regards,

Pascal

Le 3 sept. 2021 à 00:26, Lorenzo Colitti <lorenzo=[email-masked]> a écrit :

On Wed, 1 Sept 2021, 01:13 Michael Richardson, <[email-masked]<mailto:[email-masked]>> wrote:
    > It works if you're willing for routers to keep a lot of state and you have

Yes, but ND cache entries can be safely discarded because as soon as the IP address is used again, the entry is re-created.

You cannot do this with RAs because if you stop sending RAs to a given host, that host experiences an outage. So in a "unicast RA" scheme, the router is forced to keep state for all on-link hosts at all times. Without a reliable signal of when hosts go away, this doesn't scale and is subject to DoS attacks.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Sep 2021 17:55:06 +0900

And yet I keep hearing about wireless access points that will only support
4 IPv6 addresses per host because TCAM is expensive...

On Fri, Sep 3, 2021 at 2:12 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Hello Lorenzo
>
> Since 1998 the memory available in the router grew with Moore’s Law. And
> we’re using it. Clearly you do not see the router side of the fence so
> please do not take it as your argument.
>
>
> Regards,
>
> Pascal
>
> Yes, but ND cache entries can be safely discarded because as soon as the
> IP address is used again, the entry is re-created.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Sep 2021 09:11:52 +0000

I can only suppose that this confirms what I just said. Could be that you voluntarily mix things up to confuse people; but I do not like such alternatives.

Tcam is not ram; it’s not where we store the state we were talking about. It is not involved in snooping RA specifically, even less a particular ND target; as we use it for ND, it recognizes all ND messages with a few entries regardless of ND targets.

Tcam is used as a hardware component of ACL and can serve for certain activities it need to recognize individual addresses. You’d need something like that to prevent  impersonating IPv6 source addresses for instance.

Regards,

Pascal

Le 3 sept. 2021 à 10:55, Lorenzo Colitti <lorenzo=[email-masked]> a écrit :

And yet I keep hearing about wireless access points that will only support 4 IPv6 addresses per host because TCAM is expensive...

On Fri, Sep 3, 2021 at 2:12 PM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
Hello Lorenzo

Regards,

Pascal

Le 3 sept. 2021 à 00:26, Lorenzo Colitti <lorenzo=[email-masked]<mailto:[email-masked]>> a écrit :

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Sep 2021 11:21:27 +0200

Le 24/08/2021 à 21:06, Carsten Bormann a écrit :
>> I'm not sure I understand why we are using 20 of the super valuable -23->23
>> options
> 
> (Actually, -24..23 because of the way CBOR encodes negative numbers.
> [BTW, the phrasing -23-23 as in the draft is, er, hard to read.])

I agree.

If it were me writing two values I would write: -24 and -23, or -24, 
-23.  I would not use ellipsis (dots, ..)

If there were 3 values, I would use ellipsis like this: -24..-23.  I 
would not use a dash.  I would also tell this is about decimal integer 
values.

Alex

> Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Sep 2021 11:25:37 +0200

Le 25/08/2021 à 06:52, Pascal Thubert (pthubert) a écrit :
> Indeed,
> 
> Same goes for RS wouldn’t it?
> 
> The option could be stimulated by a request from a host or even a
> peer router in an RS and the RA could be  returned unicast.
> 
> So why limit the new freedom to RA?

In the past we did write drafts and implementation with an enhanced RS
containing a new bit solliciting a particular kind of prefix.  An
Universal RA option would benefit RS as well.

I think once we accept RA might advertise something else than the link
characteristics on which that RA is put (and we already did, with RDNSS
in RA), then it makes sense to put ehancements in RS; because that RS
might specify what it requests independently of the link.

Alex

> 
> Pascal
> 
>> Le 25 août 2021 à 03:55, Michael Richardson <[email-masked]>
>> a écrit :
>> 
>>  Erik Kline <[email-masked]> wrote:
>>> They could also do that today if they just include the ability
>>> for the operator to specify a byte string in hex, verify the
>>> length mod 8 is zero and that the value in 2nd byte matches the
>>> computed length, and probably also perform some check on the
>>> value of the first byte.  Other tools, like command-line-run
>>> python scripts, could handle generating the correct byte string
>>> for an operator's use case for the given ND option type.
>> 
>> Sure, you can do this after you have spent a few years to get 6man
>> to give you an option code for your 2-month experiment.
>> 
>> The multi-byte options under Expert Review are very plentiful.
>> 
>> -- Michael Richardson <[email-masked]>   . o O ( IPv6 IøT
>> consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Sep 2021 11:28:26 +0200

Le 31/08/2021 à 04:07, Lorenzo Colitti a écrit :
> On Thu, Aug 26, 2021 at 10:28 PM Pascal Thubert (pthubert) 
> <pthubert=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Here the proposal is to trigger a response that has to be specific
>     and thus unicast. Yes, this can be seen as stepping on DHCP’s feet.
>     It could also be seen as a basic router to router media. It’s mostly
>     a door opener to enable new router to router capabilities in ND,
>     independent of the other IGPs they might run. 
> 
> 
> I think that's a problem because it becomes impossible to refresh those 
> parameters via multicast RA. In order to refresh those parameters, you 
> have to either require the host to send periodic RSes (but when? How 
> does the host know when to re-send the RS? How will it know if something 
> has changed?) or require the network to send periodic unicast RA to all 
> hosts (but to which hosts? how does it know which hosts are even still 
> on the network?).

Or one might require the RSs and RAs to contain identifiers, like the 
transaction IDs in DHCP.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Sep 2021 18:36:22 +0900

Yes, TCAM is not RAM. The point here is that the router has to keep state
of every host that ever sent it an RS, and periodically send all of those
hosts RAs for as long as they are on link. If the router does not send an
RA that it needs to send, then the host experiences an outage. If the
router does not know when hosts leave the link, then it can never stop
sending RAs.

On Fri, Sep 3, 2021 at 6:12 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> I can only suppose that this confirms what I just said. Could be that you
> voluntarily mix things up to confuse people; but I do not like such
> alternatives.
>
> Tcam is not ram; it’s not where we store the state we were talking about.
> It is not involved in snooping RA specifically, even less a particular ND
> target; as we use it for ND, it recognizes all ND messages with a few
> entries regardless of ND targets.
>
> Tcam is used as a hardware component of ACL and can serve for certain
> activities it need to recognize individual addresses. You’d need something
> like that to prevent  impersonating IPv6 source addresses for instance.
>
> Regards,
>
> Pascal
>

---

From: [email-masked]
Date: Fri, 3 Sep 2021 11:49:35 +0200

Nick,

>> as a working group document. Substantive comments and statements of
>> support for adopting this document should be directed to the mailing
>> list.  Editorial suggestions can be sent to the authors.  This
>> adoption call willend on 6 September 2021.
> The most obvious issue with this draft is xkcd.com/927 and the ensuing complexity problem it creates.  For example, implementations may handle configuration options differently depending on whether they're encapsulated as RA, DHCP or universal.  You can argue that this is an implementation mistake or someone-else's-problem, but the operational reality is that multiple encapsulation mechanisms for the same underlying concepts creates the environment for implementation differences and consequently infrastructure fragility.  Lorenzo's (and Philip's) point about specification is a subset of this - this situation can be helped by having reams of documentation and test suites for each option.

This is a valid point.

One mitigation is that the Universal CI option lets you use the exact same option and option format for both DHCP and RA.
So it's independent of carrier.

I believe Jen made a point that existing options should not be represented in the U-CI option.

Which gives us two choices:
1) World domiance. Represent all current DHCP and RA options in the U-CI, with a future goal of replacing the leagcy options
2) Only new options. Thereby not creating additional conflicting options. RAs having to contain both representations for legacy hosts / updated hosts.

I can see pros and cons for both.

Best regards,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Sep 2021 11:25:23 +0000

Right, and as I said this has been the life of modern routers for a long, long while already, think, e.g., VTEPs.
Just for the sake of security / crypto we keep a pile of state in the APs and controllers that serve the STAs. We play similar games in controllers as we do in L3 switches.
If there’s a good value installing a state on the AP/router/controller RAM we’ll do it and have been for a while. I cannot see that you are complaining about that, are you?

=> seems to matter is that we’d using RS to install that state.

Yes, we could invent tons of new protocols in the next WGs. Is that preferable?
The value of using ND is to transport things that are abstract to be agnostic to the routing on the other side of the router.
So we can keep the routing side evolving with reduced hassle on the client stack.

From: Lorenzo Colitti <lorenzo=[email-masked]>
Sent: vendredi 3 septembre 2021 11:36
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Yes, TCAM is not RAM. The point here is that the router has to keep state of every host that ever sent it an RS, and periodically send all of those hosts RAs for as long as they are on link. If the router does not send an RA that it needs to send, then the host experiences an outage. If the router does not know when hosts leave the link, then it can never stop sending RAs.

On Fri, Sep 3, 2021 at 6:12 PM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
I can only suppose that this confirms what I just said. Could be that you voluntarily mix things up to confuse people; but I do not like such alternatives.

Regards,

Pascal

Le 3 sept. 2021 à 10:55, Lorenzo Colitti <lorenzo=[email-masked]<mailto:[email-masked]>> a écrit :

Regards,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 15:09:26 -0400

> represented in the U-CI option.

+1

    > Which gives us two choices: 1) World domiance. Represent all current
    > DHCP and RA options in the U-CI, with a future goal of replacing the
    > leagcy options

Given that not every network will adopt U-CI instantly, all nodes will
continue to have to process the "legacy" options.
Therefore, I see no reason to duplicate today.
Maybe in a distant future, we'll deprecate the legacy format, but I doubt it.

    > 2) Only new options. Thereby not creating additional
    > conflicting options. RAs having to contain both representations for
    > legacy hosts / updated hosts.

I prefer this.
It's pragmatic to getting the work adopted and published.

A big win might be that we wind up with a JSON format for options in
configuration files, and perhaps we can find a way to include the legacy
options in that format, without actually giving code points in the U-CI.
That is, when one sees (forgive my lack of JSONpath clue)
     "ietf" / "dns" / "dnssl"
then the router recognizes that this is a legacy option, and codes that.

I think that the examples in this should include some non-standard examples
in the JSON.  I think that it would be helpful for all.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Bob Hinden <[email-masked]>
Date: Tue, 7 Sep 2021 14:52:02 -0700

Ole,

No hats on.

> On Sep 3, 2021, at 2:49 AM, [email-masked] wrote:
> 
> Nick,
> 

I assume 1) would be completed sometime after the universal deployment of IPv6 and IPv4 being turned off  :-)

The big issue I see for 2), if it is restricted to “new options, there isn’t any way to enforce that without a lot of criteria being defined and some review process for new options.   That would, as I understand what is being proposed, defeat or significantly reduce the benefit of what is being proposed in this draft.

Bob

---

From: [email-masked]
Date: Wed, 8 Sep 2021 13:12:27 +0200

[...]

> The big issue I see for 2), if it is restricted to “new options, there isn’t any way to enforce that without a lot of criteria being defined and some review process for new options.   That would, a…

Right. In the current draft the suggestion is one of Standards action, specification required or expert review, depending on which part of the numbering space. I presume we could give guide lines to the expert reviewer about what options to accept or not.

That said, I'm unsure if we want to go there. If an option is only defined for one of them, then I think I would have preferred using a new UCI option instead of having to add a new "legacy" option in the other.

You can argue that todays situation with potential duplicate / conflicting options is already pretty bad. Think a link with nodes all implementing one or combination of RFC8106, RFC6106, RFC5006, RFC3646.

One of the motivations for proposing this was to take some of the IETF "value add" out of the equation. And see what would happen if we let those who feel they have a need for a configuration option decide for themselves what and how they want to use the mechanism.

Best regards,
Ole

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Sep 2021 07:46:15 -0400

On Wed, Sep 8, 2021 at 7:13 AM <[email-masked]> wrote:

> [...]
>
> >> One mitigation is that the Universal CI option lets you use the exact
> same option and option format for both DHCP and RA.
> >> 1) World domiance. Represent all current DHCP and RA options in the
> U-CI, with a future goal of replacing the leagcy options
> >> 2) Only new options. Thereby not creating additional conflicting
> options. RAs having to contain both representations for legacy hosts /
> updated hosts.
> >>
> > The big issue I see for 2), if it is restricted to “new options, there
> isn’t any way to enforce that without a lot of criteria being defined and
> some review process for new options.   That would, as I understand what is
> being proposed, defeat or significantly reduce the benefit of what is being
> proposed in this draft.
>
>
> Right. In the current draft the suggestion is one of Standards action,
> specification required or expert review, depending on which part of the
> numbering space. I presume we could give guide lines to the expert reviewer
> about what options to accept or not.
>
I will note DHCPv6 Options are currently "Expert Review and Standards
Action".

>
> That said, I'm unsure if we want to go there. If an option is only defined
> for one of them, then I think I would have preferred using a new UCI option
> instead of having to add a new "legacy" option in the other.
>
> You can argue that todays situation with potential duplicate / conflicting
> options is already pretty bad. Think a link with nodes all implementing one
> or combination of RFC8106, RFC6106, RFC5006, RFC3646.

This is a massive Interoperability problem at the moment for network
operators, in particular in the Enterprise space.

> One of the motivations for proposing this was to take some of the IETF
> "value add" out of the equation. And see what would happen if we let those
> who feel they have a need for a configuration option decide for themselves
> what and how they want to use the mechanism.
>
> Best regards,
> Ole
>
> Regards,
Tim

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2021 12:18:31 -0400

A question about the client side.

I think that current MS-Windows provides a way for an application to get a
custom DHCP{v6} option value from the operating system.

a) Is this correct?  Does it also allow for access to RA option values?

b) I'm unware of a standard way to do this on Linux, but perhaps systemd has
provided this in some way.

c) MacOS? Apple iOS

d) I don't think Android has any access to RA option values at the
application level.  And it doesn't do DHCPv6, but perhaps it allows for
DHCPv4 access.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Sep 2021 09:54:55 -0700

Ole, Tim,

[Combining your responses and no hats]

> On Sep 8, 2021, at 4:12 AM, [email-masked] wrote:
> 
> [...]
> 

I agree, and note this may more important than the actual encoding scheme used.

> Tim:  I will note DHCPv6 Options are currently "Expert Review and Standards Action”.

Do they require a public stable specification?

> Tim:   This is a massive Interoperability problem at the moment for network operators, in particular in the Enterprise space.

I guess the question is will this proposal make this better or worse?

> One of the motivations for proposing this was to take some of the IETF "value add" out of the equation. And see what would happen if we let those who feel they have a need for a configuration optio…

It’s a good goal, we spend way too much time “bike shedding” issues like the content of a new RA option.

Bob

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Sep 2021 13:29:47 -0400

Hi Bob,

> Do they require a public stable specification?
RFC 8126 Section 4.9
<https://datatracker.ietf.org/doc/html/rfc8126#section-4.9>says the
following:
"For the Standards Action policy, values are assigned only through
   Standards Track or Best Current Practice RFCs in the IETF Stream."

>
> >
> > That said, I'm unsure if we want to go there. If an option is only
> defined for one of them, then I think I would have preferred using a new
> UCI option instead of having to add a new "legacy" option in the other.
> >
> > You can argue that todays situation with potential duplicate /
> conflicting options is already pretty bad. Think a link with nodes all
> implementing one or combination of RFC8106, RFC6106, RFC5006, RFC3646.
>
> > Tim:   This is a massive Interoperability problem at the moment for
> network operators, in particular in the Enterprise space.
>
>
I think this will be made better by the proposal in the RFC.

> ~Tim

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Sep 2021 11:07:05 -0700

Hi Tim,

> On Sep 8, 2021, at 10:29 AM, Timothy Winters <[email-masked]> wrote:
> 
> Hi Bob,
> 
> 
> RFC 8126 Section 4.9 says the following:
>    Standards Track or Best Current Practice RFCs in the IETF Stream.”

Thanks, I note that Section 4.5. Expert Review does not require a public stabel specification.

BTW, I am assuming "Expert Review and Standards Action” really means one or the the other, not both.

> I think this will be made better by the proposal in the RFC.

How so?   Doesn’t it create a third way to do configuration?  At least for some period of transition.

Bob

---

From: Timothy Winters <[email-masked]>
Date: Wed, 8 Sep 2021 17:06:52 -0400

Hi Bob,

On Wed, Sep 8, 2021 at 2:07 PM Bob Hinden <[email-masked]> wrote:

> > >>> One mitigation is that the Universal CI option lets you use the
> exact same option and option format for both DHCP and RA.
> > >> I assume 1) would be completed sometime after the universal
> deployment of IPv6 and IPv4 being turned off  :-)
> > >>
> > >> The big issue I see for 2), if it is restricted to “new options,
> there isn’t any way to enforce that without a lot of criteria being defined
> and some review process for new options.   That would, as I understand what
> is being proposed, defeat or significantly reduce the benefit of what is
> being proposed in this draft.
> > >
> > >
It actually means both.   I've confirmed with Bernie for DHCP Options, that
it's both.

> some period of transition.
I was thinking long term with one option for both DHCP/RA, in the
transition you are correct.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Sep 2021 14:15:32 -0700

Tim,

> On Sep 8, 2021, at 2:06 PM, Timothy Winters <[email-masked]> wrote:
> 

> It actually means both.   I've confirmed with Bernie for DHCP Options, that it's both.

Thanks for clarifying.   I though I had heard earlier, that DHCP options no longer needed to be standardized.  From what you said, that isn’t the case.

Bob

> I was thinking long term with one option for both DHCP/RA, in the transition you are correct.
> 
> Bob
> 
> 
> >
> > >

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Sep 2021 16:21:28 -0700

On Fri, Sep 3, 2021 at 2:50 AM <[email-masked]> wrote:

> > The most obvious issue with this draft is xkcd.com/927 and the ensuing
> complexity problem it creates.  For example, implementations may handle
> configuration options differently depending on whether they're encapsulated
> as RA, DHCP or universal.  You can argue that this is an implementation
> mistake or someone-else's-problem, but the operational reality is that
> multiple encapsulation mechanisms for the same underlying concepts creates
> the environment for implementation differences and consequently
> infrastructure fragility.  Lorenzo's (and Philip's) point about
> specification is a subset of this - this situation can be helped by having
> reams of documentation and test suites for each option.
>
> This is a valid point.
>
> One mitigation is that the Universal CI option lets you use the exact same
> option and option format for both DHCP and RA.

<no hats>

I completely missed that recent versions grew a DHCP component.  "While
this proposal does not resolve the DHCP vs RA debate, ..." -- in fact it
completely reopens this debate.

This document would, IMHO, bifurcate IPv6 network operations forever: we'd
have RA networks and DHCP networks (enforced by the weight of large network
operators despite not being MTI).

I am now strongly opposed to adoption.  I don't think this massive change
to the architecture at this point could even be safely considered under the
"Experimental" category.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 2021 14:55:47 +1200

Erik,

See below...
On 13-Sep-21 11:21, Erik Kline wrote:
> 
> 
> On Fri, Sep 3, 2021 at 2:50 AM <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Nick,
> 
>     > The most obvious issue with this draft is xkcd.com/927 <http://xkcd.com/927> and the ensuing complexity problem it creates.  For example, implementations may handle configuration options differently depending on whether they're encapsulated as RA, DHCP or universal.  You can argue that this is an implementation mistake or someone-else's-problem, 
but the operational reality is that multiple encapsulation mechanisms for 
the same underlying concepts creates the environment for implementation differences and consequently infrastructure fragility.  Lorenzo's (and Philip's) point about specification is a subset of this - this situation can be helped by having reams of documentation and test suites for each 
option.
> I completely missed that recent versions grew a DHCP component.  "While this proposal does not resolve the DHCP vs RA debate, ..." -- in fact it completely reopens this debate.

That debate never closed, and IPv6 hosts must support both solutions for ever.

What this proposal does is open a path to feature equivalence between the 
two solutions, and it therefore calls for a rational software architecture something like:

          ----------------------
          | Apply or set       |
          | network parameters |
          ----------------------   <-- universal API
          | Receive or send    |
          | network parameters |
          ----------------------   <-- protocol-specific API
          | Recv/    | Recv/   |       
          | send     | send    |
          | RA/RS    | DHCPv6  |
          ----------------------

> 
> This document would, IMHO, bifurcate IPv6 network operations forever: we'd have RA networks and DHCP networks (enforced by the weight of large network operators despite not being MTI).

Indeed we would. How is that worse than what we have today? As long as hosts and routers have a clean software architecture, users won't care and operators can choose what they prefer. At the moment, most operators are forced to deploy both.
 
> I am now strongly opposed to adoption.  I don't think this massive 
change to the architecture at this point could even be safely considered under the "Experimental" category.

To me, experimenting with a way to rationalize the architecture seems like exactly the right thing to do.

   Brian

---

From: Erik Kline <[email-masked]>
Date: Mon, 13 Sep 2021 17:54:02 -0700

On Sun, Sep 12, 2021 at 7:55 PM Brian E Carpenter <
[email-masked]> wrote:

> >     > The most obvious issue with this draft is xkcd.com/927 <
> http://xkcd.com/927> and the ensuing complexity problem it creates.  For
> example, implementations may handle configuration options differently
> depending on whether they're encapsulated as RA, DHCP or universal.  You
> can argue that this is an implementation mistake or someone-else's-problem,
> the same underlying concepts creates the environment for implementation
> differences and consequently infrastructure fragility.  Lorenzo's (and
> Philip's) point about specification is a subset of this - this situation
> can be helped by having reams of documentation and test suites for each
> option.
> >
> >     This is a valid point.
> >

<no hats>

This diagram is missing an element labeled "resolved conflicts".

> >
> > This document would, IMHO, bifurcate IPv6 network operations forever:
> we'd have RA networks and DHCP networks (enforced by the weight of
> large network operators despite not being MTI).
>
> Indeed we would. How is that worse than what we have today? As long as
> hosts and routers have a clean software architecture, users won't care and
> operators can choose what they prefer. At the moment, most operators are
> forced to deploy both.
>

<no hats>

It would indeed be worse than what we have today.  Today we don't have to
run DHCP /at all/.  Today we /don't/ have two ways to do everything that's
required, we have only one: RS/RA.  It can deliver all the information
necessary for consistent use of the network atomically and has built-in
fate-sharing with the reachability of the router sending the RA (especially
if a node supports RFC 8028).

Not all {n -> n+1} transitions are equal:

    {0 -> 1}: a standard has been developed; huzzah; merriment ensues

    {1 -> 2}: complexity ensues resolving timing-induced bugs, priority
mismatches, and information conflicts

    {17 -> 18}: toss another dry leaf on the raging petrol fire, it doesn't
matter anymore

We are currently at {1}, and this draft would take us to {2} and unleash
more complexity than the issues already present of trying to run two
different IP stacks simultaneously (IPv4 and IPv6 with possibly separate
captive portal checks and possibly separate notifications to apps that a
network has become usable and so on).

I'm not sure I see that there is any unsolvable problem with what we have
today.

-Erik

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Sep 2021 18:27:52 -0700

On September 13, 2021 at 20:54:51, Erik Kline ([email-masked]) wrote:

+1

At an absolute minimum, this draft should not specify alternate formats for
existing options.

Separately, I haven't heard anyone talking about a real-world problem they
need to solve here.

If the real-world problem is "less review work for the working group," with
DHCP as an example of how to do things better, I would just remind the
working group that DHCP options require a specification, so you're not
actually saving yourself much work by doing this.

There is something to be said for having a standard way of conveying
information, but I have two things to say about that. First, ASN.1. Second,
I've noticed that people make wildly different choices about how to encode
things in JSON, so the fact that we will have a JSON encoding for things
does not mean that we will have eliminated the problem that different
options encode the same sort of information quite differently, and so we'll
still wind up writing per-option parsing code—it'll just be parsing data
out of the JSON instead of out of the packet.

As I said on the mic last IETF, I'm against adopting this. If we do adopt
it, it should not specify a new way of saying something we already know how
to say. Yes, someone might do that anyway, but that's not the point. The
point is that I don't want us to _specify_ two different ways to encode the
same data.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Sep 2021 11:39:05 +0900

> if a node supports RFC 8028).

Big +1.

As also previously mentioned by Tommy, we already have a way to deliver
higher-level information: the PvD Additional Information JSON option
specified by RFC 8801. That RFC clearly specifies a distinction between
bootstrapping information (which is in the RA) and additional information.
The bootstrapping information is broadcast and applies to all hosts; it is
not really secure because as multiple failed attempts have shown (secure
DHCP) it is difficult or impossible to benefit from any sort of security
other than a) TOFU or b) layering violations involving snooping tied to L2
tokens like MAC addresses or DUIDs, both of which are easily spoofable by
the device.

That additional information is already in JSON format, so it's even more
extensible as what is being proposed in this draft. It inherently
per-device and much easier to secure. That, not RA or DHCP, is where
non-bootstrapping, higher-level information should go.

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Sep 2021 06:22:36 +0200

> On 14 Sep 2021, at 03:28, Ted Lemon <[email-masked]> wrote:
> 
> There is something to be said for having a standard way of conveying information, but I have two things to say about that. First, ASN.1. Second, I've noticed that people make wildly different choices about how to encode things in JSON, so the fact that we will have a JSON encoding for things does not mean that we will have eliminated the problem that different options encode the same sort of information quite differently, and so we'll still wind up writing per-option parsing code—it'll just be parsing data out of the JSON instead of out of the packet.

If you read the draft you will see it proposes encoding using CBOR. 

O.

---

From: Ole Troan <[email-masked]>
Date: Tue, 14 Sep 2021 06:52:41 +0200

> On 14 Sep 2021, at 02:54, Erik Kline <[email-masked]> wrote:
> 
> It would indeed be worse than what we have today.  Today we don't have to run DHCP /at all/.  Today we /don't/ have two ways to do everything that's required, we have only one: RS/RA.  It can deliver all the information necessary for consistent use of the network atomically and has built-in fate-sharing with the reachability of the router sending the RA (especially if a node supports RFC 8028).

Since the solution proposed in this draft makes the configuration information independent from transport. Would you mind elaborating on why this proposal would require you to run DHCP? I would think the opposite, given that options now available only in DHCP would be available in RA also…

O.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 2021 17:17:10 +1200

> That additional information is already in JSON format, so it's even more extensible as what is being proposed in this draft. 

Huh? The proposal is CBOR, which can encode JSON.

Regards
   Brian

On 14-Sep-21 14:39, Lorenzo Colitti wrote:
> On Tue, Sep 14, 2021 at 9:54 AM Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     It would indeed be worse than what we have today.  Today we don't have to run DHCP /at all/.  Today we /don't/ have two ways to do 
everything that's required, we have only one: RS/RA.  It can deliver 
all the information necessary for consistent use of the network atomically and has built-in fate-sharing with the reachability of the router sending the RA (especially if a node supports RFC 8028).
> As also previously mentioned by Tommy, we already have a way to deliver 
higher-level information: the PvD Additional Information JSON option specified by RFC 8801. That RFC clearly specifies a distinction between bootstrapping information (which is in the RA) and additional information. The 
bootstrapping information is broadcast and applies to all hosts; it is not really secure because as multiple failed attempts have shown (secure DHCP) it is difficult or impossible to benefit from any sort of security other than a) TOFU or b) layering violations involving snooping tied to L2 tokens like MAC addresses or DUIDs, both of which are easily spoofable by 
the device.
> 
> That additional information is already in JSON format, so it's even more extensible as what is being proposed in this draft. It inherently per-device and much easier to secure. That, not RA or DHCP, is where non-bootstrapping, higher-level information should go.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Sep 2021 14:34:13 +0900

On Tue, Sep 14, 2021 at 2:17 PM Brian E Carpenter <
[email-masked]> wrote:

> extensible as what is being proposed in this draft.
>

It's even more extensible: even if, as you say, the expressive power is the
same, DHCP/RA have a size linmit, but JSON over HTTPS does not.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 2021 10:24:07 +1200

On 14-Sep-21 17:34, Lorenzo Colitti wrote:
> On Tue, Sep 14, 2021 at 2:17 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> It's even more extensible: even if, as you say, the expressive power is the same, DHCP/RA have a size linmit, but JSON over HTTPS does not.

Which conveys another point: we can't stop people inventing other ways of configuring hosts, now or in the future. If you're arguing that RFC8801 already allows what this draft does, then no doubt we also need a PvD option for DHCPv6. How widely is RFC8801 implemented?

(I had given up tracking MIF when draft-ietf-mif-mpvd-dhcp-support was abandoned, so I don't know the history of that discussion.)

    Brian

---

From: Jen Linkova <[email-masked]>
Date: Wed, 15 Sep 2021 10:10:32 +1000

On Wed, Sep 15, 2021 at 8:25 AM Brian E Carpenter
<[email-masked]> wrote:
> Which conveys another point: we can't stop people inventing other ways of configuring hosts, now or in the future.

Sure, IETF is not the Imagination Police ;) However the question is:
do all those ways need to be adopted?

Usually people implement a new mechanism because it solves some
problems with existing ones. Like "can do smth the old onces can't".
Or "can do it better".
RFC8801 does solve a number of issues with SLAAC/DHCP and nicely
complement them (so RA could contain purely network stack related
parameters, while all other things could be retrieved via HTTPS). So
do we need a 15th competing standard?

>If you're arguing that RFC8801 already allows what this draft does, then no doubt we also need a PvD option for DHCPv6.

I'm not so sure. What scenario would require such an option?
(Actually I've just started to think about mPVD + DHCPv6 and my head
is spinning now...;)

>How widely is RFC8801 implemented?

Even if it's not as widely adopted as I wish it were, I guess creating
just another way of conveying the same information would not be
useful, unless the new solution clearly identifies the problem with
previous ones.

I've just re-read the draft and I'm a bit confused with the problem
statement. The draft states:
"While this proposal does not resolve the DHCP vs RA debate, it
proposes a solution to the problem of a very slow process of
   standardizing new options, and the IETF spending an inordinate amount
   of time arguing over new configuration options.
"

Now I'm wondering if it's the case. The last time publishing an RFC
about a new option took 21 months, including:
- 3 months in the  RFC Editors queue (so the IANA option number had
been already allocated);
- 6 months when the authors were busy with other things and did not
bother to update the draft...

(I suspect that if we look at the distribution of how many drafts
published daily during a year, there will be 6 clear spikes - before
and after each IETF meeting...so maybe the best way to speed up the
standardization process is to have more meetings? :)

-- 
SY, Jen Linkova aka Furry

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Sep 2021 06:38:28 -0700

The DHC working group considered an mPVD option and rejected it because
someone who shall remain nameless patented it.  Realistically even if doing
it made sense (I don't think it does) it's a dead issue at this point.

On September 14, 2021 at 20:11:24, Jen Linkova ([email-masked]) wrote:

>If you're arguing that RFC8801 already allows what this draft does, then
no doubt we also need a PvD option for DHCPv6.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Sep 2021 06:42:41 -0700

On September 14, 2021 at 00:22:41, Ole Troan ([email-masked]) wrote:

I did read the draft. CBOR is essentially a binary encoding for JSON, and
does have the problem I mentioned: the mere fact that there is a standard
way of encoding JSON-like data does not mean that everyone will use the
same encoding for every data type. I didn't mean to suggest that the draft
is using JSON directly. Sorry for the confusion.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Sep 2021 06:46:31 -0700

I can't speak for Erik, but I understood him to mean that because we now
have multiple ways of encoding the same information in RAs, we have a
similar addition to the decision tree when considering what values to use:
do I use the CBOR-encoded value, or the legacy encoded version, when both
are present? Of course we don't actually want both to be present, but the
legacy-encoded version /has/ to be present, because old devices won't
understand the new encoding. So then when I'm writing code that supports
the new encoding, I have to assume it's possible for the data to be in
conflict, and now I have to write conflict-resolution code.

This is the exact problem we already have with DHCPv6, hence the reference
to DHCPv6.

On September 14, 2021 at 00:53:16, Ole Troan ([email-masked]) wrote:

Since the solution proposed in this draft makes the configuration
information independent from transport. Would you mind elaborating on why
this proposal would require you to run DHCP? I would think the opposite,
given that options now available only in DHCP would be available in RA also…

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Sep 2021 15:55:24 +0200

> CBOR is essentially a binary encoding for JSON,

For a definition of “essence” :-)

> and does have the problem I mentioned: the mere fact that there is a standard way of encoding JSON-like data does not mean that everyone will use the same encoding for every data type. 

That is actually another(*) difference between JSON and CBOR:
In CBOR, we try to have standard data types for many things (they are called “tags”).
These may help in getting some additional commonality.

(The fundamental problem you point out doesn’t go away, but does get mitigated a lot.)

Grüße, Carsten

(*) CBOR = JSON + binary + extensibility

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Sep 2021 10:19:54 +1200

> The DHC working group considered an mPVD option and rejected it because 
someone who shall remain nameless patented it. Realistically even if 
doing it made sense (I don't think it does) it's a dead issue at this point.

"Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee"

I think you might find a number of Proposed Standards with such disclosures
against them. If PVDs catch on, this may well come back again.

> On September 14, 2021 at 20:11:24, Jen Linkova ([email-masked] <mailto:[email-masked]>) wrote:
> 

Certainly, things are clearer if everything to do with routing
and address selection comes from the first-hop routers. But if
a site operator chooses to rely on DHCPv6, they don't want to
do more than the bare minimum with RA. I don't think that the
IETF wanting this to be different will change it.

   Brian

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Sep 2021 15:38:22 +0900

On Fri, Aug 27, 2021 at 5:34 AM Brian E Carpenter <
[email-masked]> wrote:

> That's exactly what I mean: we don't have feature equivalence, which means
> there is zero hope of paring back to a single solution. The universal
> option is a possible path to a single solution in the long term.
>

That sounds good at first glance but it hides a deeper problem: even if we
put the same *options* in DHCP and RA, the *semantics* are different,
because the delivery mechanisms are different. Specifically:

   - DHCP options need to be renewed by the client, are unicasted to
   particular devices, cannot be updated (due to general lack of reconfigure
   support), and don't share fate with routing infrastructure.
   - RA options are renewed, are refreshed via multicast updates to all
   devices, can be updated at any time, and share fate with routing
   infrastructure.

So, let's say that someone were to define a universal option for the
default router. If operators put that in an RA, it would correctly share
fate with routing and could be updated when the default router changed. If
operators put it in DHCPv6, then it would be incorrect: no fate sharing, no
ability to update.

What this means is that anyone defining an option or deploying this option
wil have to think carefully about the semantics of the option *in both
delivery mechanisms*. I think that argues pretty strongly against this
proposal.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Sep 2021 15:39:48 +1200

On 16-Sep-21 18:38, Lorenzo Colitti wrote:
> On Fri, Aug 27, 2021 at 5:34 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     That's exactly what I mean: we don't have feature equivalence, which means there is zero hope of paring back to a single solution. The universal option is a possible path to a single solution in the long term.
> 
> 
> That sounds good at first glance but it hides a deeper problem: even if we put the same *options* in DHCP and RA, the *semantics* are different, because the delivery mechanisms are different. Specifically:
> 
>   * DHCP options need to be renewed by the client, are unicasted to particular devices, cannot be updated (due to general lack of reconfigure support), and don't share fate with routing infrastructure.
>   * RA options are renewed, are refreshed via multicast updates to all devices, can be updated at any time, and share fate with routing infrastructure.
> 
> So, let's say that someone were to define a universal option for the default router. If operators put that in an RA, it would correctly share fate with routing and could be updated when the default router changed. If operators put it in DHCPv6, then it would be incorrect: no fate sharing, no ability to update.
> 
> What this means is that anyone defining an option or deploying this option wil have to think carefully about the semantics of the option *in both delivery mechanisms*. 

True. What bothers me about this whole issue is that with RA and DHCPv6 we have neither feature equivalence nor feature separation; we have feature overlap. I think that's the worst option, but it's the status quo, and I don't really know how to fix it.

> I think that argues pretty strongly against this proposal.

My thought is that this proposal is the only possible way out of the status quo. Well, the WG chair who isn't a co-author has seen all the arguments by now...

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Sep 2021 12:49:36 +0900

On Fri, Sep 17, 2021 at 12:39 PM Brian E Carpenter <
[email-masked]> wrote:

> > What this means is that anyone defining an option or deploying this
> option wil have to think carefully about the semantics of the option *in
> both delivery mechanisms*.
>
> True. What bothers me about this whole issue is that with RA and DHCPv6 we
> have neither feature equivalence nor feature separation; we have feature
> overlap. I think that's the worst option, but it's the status quo, and I
> don't really know how to fix it.
>
> My thought is that this proposal is the only possible way out of the
> status quo. Well, the WG chair who isn't a co-author has seen all the
> arguments by now...
>

IMO the right way out of the status quo is to leave bootstrapping
configuration in RA, move all app-level configuration to the JSON PVD
option, and deprecate DHCPv6.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 17 Sep 2021 16:20:30 +0100

> option, and deprecate DHCPv6.

Is this an aspiration that DHCPv6 would go away if the IETF issued a 
collective harrumph about it? :-)

Nick

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 02:22:09 -0300

Hi, Brian,

> True. What bothers me about this whole issue is that with RA and DHCPv6 we have neither feature equivalence nor feature separation; we have feature overlap. I think that's the worst option, but it'…

Fully agreed.

How to "fix" it? -- standardize any remaining bits that essentially
requires you to use one protocol, when you want to use the other.

e.g., for the DHCPv6 case that would mean specifying a default route
option (anything else?).

for the SLAAC case... I guess it could be some form PD, if possible/doable?

> My thought is that this proposal is the only possible way out of the status quo. Well, the WG chair who isn't a co-author has seen all the arguments by now...

Well, that'd be the case if what prevented us from solving the
aforementioned problem was to figure out the syntax for options in one
protocol or another.

But I think the problem has been strong opposition (by some) to
specifying such options/features, rather than our inability to come up
with an appropriate syntax/encoding.

FWIW, this is not an argument against this option, but rather a call to
specify what we need to specify *if* we want to solve the issue at hand.

Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 21 Sep 2021 07:51:44 +0000

Hi Fernando,
The idea "standardize any remaining" looks good but SLAAC and DHCP are so different by architecture that it would not be possible.
Example: DHCP is the choice for all types of businesses because of traceability (billing, troubleshooting, forensic) but SLAAC is silent in principle.
Hence, SLAAC would be stuck in use cases where it is enforced by one company. If not this support SLAAC would be dead by now.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Tuesday, September 21, 2021 8:22 AM
To: Brian E Carpenter <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Hi, Brian,

Fully agreed.

How to "fix" it? -- standardize any remaining bits that essentially requires you to use one protocol, when you want to use the other.

e.g., for the DHCPv6 case that would mean specifying a default route option (anything else?).

> My thought is that this proposal is the only possible way out of the status quo. Well, the WG chair who isn't a co-author has seen all the arguments by now...

Well, that'd be the case if what prevented us from solving the aforementioned problem was to figure out the syntax for options in one protocol or another.

But I think the problem has been strong opposition (by some) to specifying such options/features, rather than our inability to come up with an appropriate syntax/encoding.

FWIW, this is not an argument against this option, but rather a call to specify what we need to specify *if* we want to solve the issue at hand.

Thanks,

---

From: [email-masked]
Date: Tue, 21 Sep 2021 10:19:26 +0200

Fernando,

[...]

> with an appropriate syntax/encoding.

Agree. That's the second dimension of the proposal. Framed as an experiment.
What would happen if we took the IETF out of the equation? Let those in need for a configuration option define that in the IANA registry with expert review.

Best regards,
Ole

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Sep 2021 15:37:33 +0100

[email-masked] wrote on 21/09/2021 09:19:
> What would happen if we took the IETF out of the equation?
in the wider sense of the question, dhcp would likely evolve prefix 
assignment, a routing option and the ability to operate independently of 
RA. Over time, RA would possibly become more of a niche thing, 
regardless of its formal status as a must-support.

In the context of the the universal-ra-option draft, it's difficult to 
see what the likely long term outcome is going to be because the draft 
would require widespread commitment to a different low-level protocol 
option coding before it would become useful enough to want to support 
it. This creates a substantial implementation barrier.

Ultimately, your question reiterates that the primary reason to specify 
the universal RA option is to dig the ietf out of its own political 
log-jam, and implementers would need to add this consideration into the 
sausage machines of their decision-making processes.  There would be 
good reasons to think twice before implementing in this context.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Sep 2021 00:39:51 +0900

> regardless of its formal status as a must-support.

That seems like a very bad outcome because the routing and addressing
semantics of RAs are better than those of DHCP.

In particular, RAs provide natural fate sharing with the routing
infrastructure, support multiple sources of information, and allow updates.
DHCP does not share fate with routing, only supports one source of
information (the client chooses among multiple offers), and does not
support updates (well, technically it supports updates, but I don't think
many clients support reconfigure, and also, if the infrastructure loses
state then reconfiguring existing clients is not possible because the keys
are gone).

DHCP's inability to support updates is a problem because when the network
configuration changes for whatever reason then it's not possible to inform
the client of the change. This generally means that the network must ensure
clients have a stable configuration until they issue a renew.

DHCP works pretty well in IPv4 where the network can ensure stable
configuration using NAT. If you use end-to-end addressing I think it's much
more limiting.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 13:31:04 -0300

On 21/9/21 12:39, Lorenzo Colitti wrote:
> On Tue, Sep 21, 2021 at 11:38 PM Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]> wrote on
>     21/09/2021 09:19:

They just serve a different purpose. There's certainly a place for
DHCPv6, at least in enterprise deployments.

I'm not sure why the IETF should rule which of the two to use.

OTOH, let's be fair here: Unless you are assuming/implying that (the
unfortunately seldomly implemented) RFC8028 is in place, SLAAC is
totally broken for multi-prefix/multi-router environments.

At the time of this writing, RFC8028 is as unsupported as DHCPv6
reconfigure.

> infrastructure, support multiple sources of information, and allow

Which, without RFC8028 and draft-ietf-6man-slaac-renum (yes, nudge to
myself to rev this week), is the perfect source for problems.

The "every router throws info on the link, and host will figure out what
to do" hasn't worked well so far. And without things like RFC8028 and
draft-etf-6man-slaac-renum, it;s actually quite broken.

> DHCP's inability to support updates is a problem because when the
> network configuration changes for whatever reason then it's not possible
> to inform the client of the change. This generally means that the
> network must ensure clients have a stable configuration until they issue
> a renew.
>
> configuration using NAT. If you use end-to-end addressing I think it's
> much more limiting.

Unstable network configuration is also a problem for SLAAC: RFC8978.

I experience that on a regular basis at my IPv6-enabled home.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 13:45:13 -0300

Hi, Ole,

> What would happen if we took the IETF out of the equation? Let those in need for a configuration option define that in the IANA registry with expert review.

My only concern in this regard was for incompatibilities to arise as a
result of under-specified behavior.

But I guess that if we're unable to address this well-known issue,
that's a risk we'd have to cope with in order to deal with that.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 13:48:17 -0300

> Example: DHCP is the choice for all types of businesses because of traceability (billing, troubleshooting, forensic) but SLAAC is silent in principle.

Agreed on that.

For DHCPv6 that means "standardize a default route option, and be done
with it"... unless we want to be the protocol police, I guess?

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 21 Sep 2021 16:50:21 +0000

RFC8028 is too general to fix MHMP problem. It is just a good idea.
We have specified here more details: https://www.ietf.org/archive/id/draft-vv-6man-nd-prefix-robustness-00.txt
Section 5.1 (then 6.1) proposes enough details.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Tuesday, September 21, 2021 7:31 PM
To: Lorenzo Colitti <lorenzo=[email-masked]>; Nick Hilliard <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

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

They just serve a different purpose. There's certainly a place for DHCPv6, at least in enterprise deployments.

OTOH, let's be fair here: Unless you are assuming/implying that (the unfortunately seldomly implemented) RFC8028 is in place, SLAAC is totally broken for multi-prefix/multi-router environments.

At the time of this writing, RFC8028 is as unsupported as DHCPv6 reconfigure.

> infrastructure, support multiple sources of information, and allow 

Which, without RFC8028 and draft-ietf-6man-slaac-renum (yes, nudge to myself to rev this week), is the perfect source for problems.

The "every router throws info on the link, and host will figure out what to do" hasn't worked well so far. And without things like RFC8028 and draft-etf-6man-slaac-renum, it;s actually quite broken.

> network configuration changes for whatever reason then it's not 
> possible to inform the client of the change. This generally means that 
> the network must ensure clients have a stable configuration until they 
> issue a renew.
>

Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531 “This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Sep 2021 18:57:09 +0200

Fernando,

> that's a risk we'd have to cope with in order to deal with that.

True. If we are going down this road, the document should probably include reasonable guidance to the expert reviewer. One could imagine someone implementing new protocols with this option. At least if allowed in RS/Request. :-)

Cheers 
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 21 Sep 2021 17:03:33 +0000

It was many times in IETF history: if we have many protocols to achieve the same
Then the progress in this direction would be slow.

DHCP is more universal. Hence, if somebody would push - I am sure that DHCP would win the voting.

It is possible to add "sharing fate with infrastructure" for DHCP:
If the default gateway router is deprecated - then renew all DHCP information that was received through it.

I do not understand why "default router" is so much needed on DHCP. Why not leave it on RA?
Addresses and prefixes are better to put on DHCP.

Ed/
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, September 21, 2021 7:48 PM
To: Vasilenko Eduard <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Agreed on that.

For DHCPv6 that means "standardize a default route option, and be done with it"... unless we want to be the protocol police, I guess?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 14:28:14 -0300

> Then the progress in this direction would be slow.

Here we have none. In many scenarios, for different reasons, you
currently may need *both*.

And, if not having both protocols fully overlap was actually a strategy
to not hinder IPv6 deployment... maybe reality is calling us to
re-evaluate that one.

> DHCP is more universal. Hence, if somebody would push - I am sure that DHCP would win the voting.

That's indeed the point: given that DHCPv6 is the operating model that
we have employed for decades, and that probably the only remaining bit
is a default route option, why should  *you* vote on what *I* run on
*my* network?

> Addresses and prefixes are better to put on DHCP.

Because that calls for config information in two different places. And
in some environments, for two different teams to be involved.

e.g., in the IPv4 world, you may have the IT or sysadmin team handle of
all this config (along with AD and other stuff), whereas without a
default route option, you'd probably now have to involve the Network team.

Note: there are many environments where I couldn't care less about
what's the underlying mechanism that is employed for network config.

But where I do have a preference, I do find it disappointing when folks
want to make that choice for me (*).

(*) Particularly given the situation where there is partial overlap
among the two protocols.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Sep 2021 04:21:48 +1000

On Wed, 22 Sep 2021, 03:28 Fernando Gont, <fernando.gont=
[email-masked]> wrote:

> > If the default gateway router is deprecated - then renew all DHCP
> information that was received through it.
> >

The sysadmin team don't run everything if they're running DHCPv4 servers.
They have to come and ask the network team what the subnet addressing range
and default gateway address is to then it put into the DHCPv4 server.
System teams don't do IPv4 subnet addressing planning and allocation when
there are separate system and network teams.

The RA / DHCPv6 split we have today (excepting addresses in DHCPv6, and DNS
in RAs) aligns with both the system and network role boundaries and the
Internet protocol layer model.

The network layer parameters are provided by RAs, from the devices the
network admins operate - routers.

The application layer parameters are provided by DHCPv6, from the devices
the system admins operate - the DHCPv6 servers.

The advantage of keeping this split is that DHCPv6 could be replaced
without having to change anything in the network. Alternatively, network
layer RAs could be replaced without having to change the upper layer DHCPv6
configuration protocol.

Host application layer configuration should use an "over the top"
configuration protocol for the same reason that transport layer and
application layer protocols are "over the top" - so the network doesn't
have to be changed to accommodate new application configuration options, or
even an entirely new application configuration protocol.

(Stateless DHCPv4 and DHCPv6 relays in routers is a bit of a layer
violation, however at least they're DHCP option transparent, so newly
created DHP options can be deployed by just updating the DHCP clients and
servers. Perhaps if multicast or anycast were available at the time of
BOOTP development, they would have been used instead of a stateless BOOTP
relay in routers.)

Regards,
Mark.

> “This communication is the property of EdgeUno or one of its group
> companies and/or affiliates. This electronic message contains information
> which may be privileged or confidential. The information is intended to be
> for the exclusive use of the individual(s) named above and if you are not
> the intended recipient be aware that any non-explicitly authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited, and will be considered a criminal offense. Please notify
> [email-masked] about the unintended receipt of this electronic message
> and delete it.”
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 21 Sep 2021 19:04:14 +0000

Sorry, I still do not understand why the default router should be on DHCP.
It is just 1 bit: "I am the router on this link". Almost always activated bit. No choice, no parameters. Easy to demarcate between different teams.

What is really a challenge: the prefix announced through the particular interface ("PIO"). The router should know where is this subnet.
If prefix would be delivered through DHCP then the router should snoop and appoint the appropriate prefix to the interface.
Probably you mean this challenge under the name "default router". I propose snooping on the router side to learn prefixes.
By the way, IPv4 world does not have any automation here (like snooping) - they coordinate it manually between teams.
The situation is more challenging for IPv6 - many prefixes need to be coordinated. Hence, more importance for automation of this process.

Ed/
-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, September 21, 2021 8:28 PM
To: Vasilenko Eduard <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

On 21/9/21 14:03, Vasilenko Eduard wrote:
> It was many times in IETF history: if we have many protocols to 
> achieve the same Then the progress in this direction would be slow.

Here we have none. In many scenarios, for different reasons, you currently may need *both*.

And, if not having both protocols fully overlap was actually a strategy to not hinder IPv6 deployment... maybe reality is calling us to re-evaluate that one.

> DHCP is more universal. Hence, if somebody would push - I am sure that DHCP would win the voting.

That's indeed the point: given that DHCPv6 is the operating model that we have employed for decades, and that probably the only remaining bit is a default route option, why should  *you* vote on what *I* run on
*my* network?

> Addresses and prefixes are better to put on DHCP.

Because that calls for config information in two different places. And in some environments, for two different teams to be involved.

e.g., in the IPv4 world, you may have the IT or sysadmin team handle of all this config (along with AD and other stuff), whereas without a default route option, you'd probably now have to involve the Network team.

Note: there are many environments where I couldn't care less about what's the underlying mechanism that is employed for network config.

But where I do have a preference, I do find it disappointing when folks want to make that choice for me (*).

(*) Particularly given the situation where there is partial overlap among the two protocols.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 16:48:57 -0300

> It is just 1 bit: "I am the router on this link". Almost always activated bit. No choice, no parameters. Easy to demarcate between different teams.

I didn't say "it should be in DHCP". I rather noted that in many cases,
and administrator may want to configure different kinds of policies
which, if configured via SLAAC, would normally require access to devices
that such teams may have no access to.

> By the way, IPv4 world does not have any automation here (like snooping) - they coordinate it manually between teams.

In IPv4, a network team can tell you which IP addresses can be employed
as a default route, and another team may enforce whatever policy they
please (i.e., router vs server config). In SLAAC IPv6, policy is on the
router itself.

Depending on the scenario, you may not bother even thinking about this.
In others, it may be a hassle, to say the least.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Sep 2021 09:13:26 +1200

> Hence, SLAAC would be stuck in use cases where it is enforced by one company. If not this support SLAAC would be dead by now.

Absolutely not. It isn't "enforced by one company". It does exactly what it was designed
to do, what we called "the dentist's office scenario" in the early days of IPng design, actually modelled mainly on Appletalk. You can hook a few IPv6 boxes together on a wire and they will start talking to each other using SLAAC and link-local addresses. Add a router with a prefix and they will start talking to the world using SLAAC and RA. DHCPv6 is completely unnecessary until the network reaches a certain level of complexity.

The problem area isn't the simultaneous existence of SLAAC/RA and DHCPv6. It's that they don't play well together. Maybe we should restate the problem as "how to make SLAAC/RA play together better". And task a design team with that problem.

> It is just 1 bit: "I am the router on this link". Almost always activated bit. No choice, no parameters. Easy to demarcate between different teams.

Well indeed, the value comes when there are several routers (hence RFC8028). If you would like an equivalent of that functionality in DHCPv6, please specify it.

(And BTW it is, to my understanding, implemented on the host side. If operators ask for it, no doubt it will appear on the router side.)

> Probably you mean this challenge under the name "default router". 

One thing about RFC8028 is that it shows that the phrase "default router" is insufficient, because the host needs to know the best router for a given prefix, not a general default.

> I propose snooping on the router side to learn prefixes.

Indeed. I think that is why we had the MIF WG. Any sign of PVDs in the real world?

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Sep 2021 17:51:58 -0400

Quick comment.

SLAAC and DHCPv6 play well together in my experience, however I think the
playing well maybe vendor implementation specific.

The M/O bits control stateful nature and various bit combinations, however
for simplicity as long as M=1 a managed address is sent by DHCP relay &
reply back to the hosts on the subnet.

As for SLAAC, the router prefix and Default route is sent via the RA, and I
believe most vendors have that knob enabled by default.

So hosts get both a stateful I believe Windows flags as “public” address as
well as a SLAAC address.

Windows dos prompt  command
“netsh interface ipv6 show address”

“netsh interface ipv6 show interface <index>“ shows the M/O bits received
and cached by the host.

There is a vendor specific knob “ipv6 be default no-advertise” which
disabled SLAAC so the host only gets DHCPv6 address.

Without the knob disabled the host gets both addresses and then used
Default address selection to pick which to use.

As long as the subnet is a /64 as SLACA has the /64 RFC 4862 requirement
then all 3 addressing methods static, DHCPv6 and SLAAC can live together on
the same subnet.

Kind Regards

Gyan

On Tue, Sep 21, 2021 at 5:13 PM Brian E Carpenter <
[email-masked]> wrote:

> > The idea "standardize any remaining" looks good but SLAAC and DHCP are
> so different by architecture that it would not be possible.
> > Example: DHCP is the choice for all types of businesses because of
> traceability (billing, troubleshooting, forensic) but SLAAC is silent in
> principle.
> > Hence, SLAAC would be stuck in use cases where it is enforced by one
> company. If not this support SLAAC would be dead by now.
>
> to do, what we called "the dentist's office scenario" in the early days of
> IPng design, actually modelled mainly on Appletalk. You can hook a few IPv6
> boxes together on a wire and they will start talking to each other using
> SLAAC and link-local addresses. Add a router with a prefix and they will
> start talking to the world using SLAAC and RA. DHCPv6 is completely
> unnecessary until the network reaches a certain level of complexity.
>
> The problem area isn't the simultaneous existence of SLAAC/RA and DHCPv6.
> It's that they don't play well together. Maybe we should restate the
> problem as "how to make SLAAC/RA play together better". And task a design
> team with that problem.
>
> > It is just 1 bit: "I am the router on this link". Almost always
> activated bit. No choice, no parameters. Easy to demarcate between
> different teams.
>
> Well indeed, the value comes when there are several routers (hence
> RFC8028). If you would like an equivalent of that functionality in DHCPv6,
> please specify it.
>
> (And BTW it is, to my understanding, implemented on the host side. If
> operators ask for it, no doubt it will appear on the router side.)
>
> >
> > What is really a challenge: the prefix announced through the particular
> interface ("PIO"). The router should know where is this subnet.
> > If prefix would be delivered through DHCP then the router should snoop
> and appoint the appropriate prefix to the interface.
> One thing about RFC8028 is that it shows that the phrase "default router"
> is insufficient, because the host needs to know the best router for a given
> prefix, not a general default.
>
> > By the way, IPv4 world does not have any automation here (like snooping)
> - they coordinate it manually between teams.
> > The situation is more challenging for IPv6 - many prefixes need to be
> coordinated. Hence, more importance for automation of this process.
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Sep 2021 08:11:35 +1000

> traceability (billing, troubleshooting, forensic) but SLAAC is silent in

Can't find Eduard's original, so I'll comment here.

DHCPv6 and DHCPv4 were never designed for billing or forensic uses.

DHCP of both flavours does not record IP addresses in use.

DHCPv4 doesn't record manually configured IPv4 addresses. DHCPv6 doesn't
record manually configured IPv6 addresses or link-local addresses.

The only thing DHCP keeps is a database of DHCP clients.

If you want address traceability, you need a solution that works regardless
of how IPv6 addresses are configured or generated, be it manually, via
SLAAC or via DHCPv6.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Sep 2021 19:35:15 -0300

On 21/9/21 18:51, Gyan Mishra wrote:
>
> Quick comment.
>
> SLAAC and DHCPv6 play well together in my experience, however I think
> the playing well maybe vendor implementation specific.

I guess it's simply a matter of what one means by "well". Me, I'd expect
some sort of predictabile/deterministic behavior. But e.g. this:
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcpv6-slaac-problem-07
argues that that's usually not the case.

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 21 Sep 2021 21:31:12 -0500

> of how IPv6 addresses are configured or generated, be it manually, via

If folks are not familiar with it, there is some discussion on this 
in RFC7934 Section 9.1:

https://datatracker.ietf.org/doc/html/rfc7934#section-9.1

Dale

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 Sep 2021 09:57:04 +0100

> semantics of RAs are better than those of DHCP.

"better" without context is no more than a statement of personal 
preference.  Whether the addressing semantics of RAs are "better" than 
DHCP depends on the deployment case and the desired performance 
characteristics, regardless of the opinions expressed in rfc7934 and 
other documents.

The other points in your email come up every time the slaac-vs-dhcpv6 
argument is given an airing, and there's extensive discussion about why 
your claims about dhcpv6 are overblown or, depending on the context, 
factually wrong.  No doubt RAs work for the intersection of use cases 
and policy requirements that you deal with, but this is not the 
universal experience.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Wed, 22 Sep 2021 11:45:13 +0200

>Internet protocol layer model.

There seems to a notion promoted by the proponents of RAs that hosts
do not need unique, per host configurable default routers. Obviously,
in it's current form, RA cannot provide that. 

At the same time, there are networks that a decade or longer have had the
same IP address as default router. Somehow proponents of RA claim that it
is very important to have fate sharing. Even though in practice this does
not offer anything to hosts. The fate sharing provided by a router not sending
RAs happens on a time scale (tens of minutes) that is not suitable for
today's environment. In practice, hosts have to rely on reachability 
etection in ND to determine if a default router can be used or not.

So instead of creating operational flexiblity where operators can decide how
to run their networks, the result of this working group seems to be to
try to kill all concepts that don't fit into the RA mold.

In don't think this draft is a solution though. We need well thought out and
well written standards. Not an openended system where the real protocol is 
just a custom created by dominant parties.

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 22 Sep 2021 13:12:39 +0000

Hi Brian,
The world has changed 5 years after "the dentist's office scenario" was discussed (by the way - it did happen 2 decades ago). This scenario is outdated now.
Because modern "dentist's office" would be mandatorily connected to the Internet by the router that could easily have a local DHCP server.
The only absence of DHCP support on the one popular OS is keeping SLAAC alive.
Eduard
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2021 12:13 AM
To: Vasilenko Eduard <[email-masked]>; Fernando Gont <fernando.gont=[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

> Hence, SLAAC would be stuck in use cases where it is enforced by one company. If not this support SLAAC would be dead by now.

Absolutely not. It isn't "enforced by one company". It does exactly what it was designed to do, what we called "the dentist's office scenario" in the early days of IPng design, actually modelled mainly on Appletalk. You can hook a few IPv6 boxes together on a wire and they will start talking to each other using SLAAC and link-local addresses. Add a router with a prefix and they will start talking to the world using SLAAC and RA. DHCPv6 is completely unnecessary until the network reaches a certain level of complexity.

    Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 22 Sep 2021 13:21:49 +0000

Hi Mark,
I strictly disagree that DHCP has no traceability. All servers have logs. 2 examples:
https://support.huawei.com/enterprise/en/doc/EDOC1100008296/39e96b03/dhcp-server-logging
https://helpcenter.netwrix.com/NA/Configure_IT_Infrastructure/Windows_Server/DHCP_Operational_log.html

LLA indeed could not be traced because it could not be assigned by DHCP☹
The good news is that LLA is not interested in billing and most cases not interested in forensic. Troubleshooting could be still the challenge.
Eduard
From: Mark Smith [mailto:[email-masked]]
Sent: Wednesday, September 22, 2021 1:12 AM
To: Brian E Carpenter <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; Fernando Gont <fernando.gont=[email-masked]>; Lorenzo Colitti <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

On Wed, 22 Sep 2021, 07:14 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:

DHCPv4 doesn't record manually configured IPv4 addresses. DHCPv6 doesn't record manually configured IPv6 addresses or link-local addresses.

If you want address traceability, you need a solution that works regardless of how IPv6 addresses are configured or generated, be it manually, via SLAAC or via DHCPv6.

Regards,
Mark.

    Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 22 Sep 2021 13:42:02 +0000

Hi Gyan,
Just try to find a vendor that would be capable to support redundancy for SOHO. "the dentist's office scenario"
i.e. 2 routers connected to different Carriers.
MHMP (multi-home multi-prefix environment) still does not work. The traffic drop probability would be 50%.
It is partially because of SLAAC – need to support the self-appointment of IPv6 addresses.
Yes, I know that there are RFC 8028 general recommendations. Is any implementation exist?
It is the year 2021 (+25 years). We are discussing “network programmability”, “application-awareness”, and so on.
But basic redundancy is not possible…
At the time when IPv6 has been developed – it was popular to talk about the KISS design principle. It is broken in IPv6.
Flexibility always comes with complexity, then with low security. KISS.
My conclusion: IPv6 needs radical simplification. SLAAC is the 1st candidate because distributed intelligence is always complex.
Eduard
From: Gyan Mishra [mailto:[email-masked]]
Sent: Wednesday, September 22, 2021 12:52 AM
To: Brian E Carpenter <[email-masked]>
Cc: Fernando Gont <fernando.gont=[email-masked]>; IPv6 List <[email-masked]>; Lorenzo Colitti <[email-masked]>; Vasilenko Eduard <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Quick comment.

SLAAC and DHCPv6 play well together in my experience, however I think the playing well maybe vendor implementation specific.

The M/O bits control stateful nature and various bit combinations, however for simplicity as long as M=1 a managed address is sent by DHCP relay & reply back to the hosts on the subnet.

As for SLAAC, the router prefix and Default route is sent via the RA, and I believe most vendors have that knob enabled by default.

So hosts get both a stateful I believe Windows flags as “public” address as well as a SLAAC address.

“netsh interface ipv6 show interface <index>“ shows the M/O bits received and cached by the host.

There is a vendor specific knob “ipv6 be default no-advertise” which disabled SLAAC so the host only gets DHCPv6 address.

Without the knob disabled the host gets both addresses and then used Default address selection to pick which to use.

As long as the subnet is a /64 as SLACA has the /64 RFC 4862 requirement then all 3 addressing methods static, DHCPv6 and SLAAC can live together on the same subnet.

Kind Regards

Gyan

On Tue, Sep 21, 2021 at 5:13 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

    Brian

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 22 Sep 2021 13:47:25 +0000

For sure it is possible to collect logs from many network devices then aggregate.
But DHCP has a centralized facility for it with well-developed software and integration to DNS.
Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Dale W. Carder
Sent: Wednesday, September 22, 2021 5:31 AM
To: Mark Smith <[email-masked]>
Cc: Fernando Gont <fernando.gont=[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Thus spake Mark Smith ([email-masked]) on Wed, Sep 22, 2021 at 08:11:35AM +1000:
> > traceability (billing, troubleshooting, forensic) but SLAAC is 
> > silent in principle.
> >
> 
> 
> DHCPv4 doesn't record manually configured IPv4 addresses. DHCPv6 
> doesn't record manually configured IPv6 addresses or link-local addresses.
> 
> If you want address traceability, you need a solution that works 
> regardless of how IPv6 addresses are configured or generated, be it 
> manually, via SLAAC or via DHCPv6.

If folks are not familiar with it, there is some discussion on this in RFC7934 Section 9.1:

Dale

---

From: Philip Homburg <[email-masked]>
Date: Wed, 22 Sep 2021 15:49:28 +0200

>It does exactly what it wa
>s designed
>to do, what we called "the dentist's office scenario" in the early days of IPn
>g design, actually modelled mainly on Appletalk. You can hook a few IPv6 boxes
> together on a wire and they will start talking to each other using SLAAC and 
>link-local addresses. Add a router with a prefix and they will start talking t
>o the world using SLAAC and RA. DHCPv6 is completely unnecessary until the net
>work reaches a certain level of complexity.

I'm confused about the relevance of the "the dentist's office scenario".

As far as I know, the "the dentist's office scenario" is when there is no
router of any kind on a subnet. Both RA and DHCP are equally irrelevant.
That scenario seems completely unrelated to this discussion. Basically the
support we have for the "the dentist's office scenario" is that hosts
automatically configure a link-local address. Nothing more nothing less.

These days, most devices communiate over wifi. And it is hard to find
a wifi access point in a dentist's office that doesn't have a built-in router.

As the current IPv4 network shows, even the smallest networks work fine 
with DHCP. DHCP in modern CPEs is completely automatic. So the notion
that a small network would need something like RA is rather weird.

Where RA goes beyond DHCP is in supporting multiple default routers. Which
is no longer a small, simple network. And in my experience, having multiple
routers announcing their own prefixes, creates interesting corner cases.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Sep 2021 15:39:51 -0400

Philip Homburg <[email-masked]> wrote:
    > At the same time, there are networks that a decade or longer have had
    > the same IP address as default router. Somehow proponents of RA claim
    > that it is very important to have fate sharing. Even though in practice

I think that this is an unfair generalization.
It's certainly true for many hosts.

There are many kinds of networks and many kinds of hosts, and I think that we
are doing ourselves a disservice to try to hit them all with the same hammer.

    > this does not offer anything to hosts. The fate sharing provided by a
    > router not sending RAs happens on a time scale (tens of minutes) that
    > is not suitable for today's environment. In practice, hosts have to
    > rely on reachability etection in ND to determine if a default router
    > can be used or not.

    > So instead of creating operational flexiblity where operators can
    > decide how to run their networks, the result of this working group
    > seems to be to try to kill all concepts that don't fit into the RA
    > mold.

I think that's an unfair characterization of the WG.
It does look that way by message count, but I think that we have some very
loud individuals.

    > In don't think this draft is a solution though. We need well thought
    > out and well written standards. Not an openended system where the real
    > protocol is just a custom created by dominant parties.

I don't really know how universal-ra has anything to do with DHCP vs RA.
universal-ra is about being able to do experiments or other minor things in
RA space without having to wait three years for your router vendor to include

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Sep 2021 08:53:50 +1200

Eduard,

Obviously, "dentist's office" is not to be taken literally. (Regardless of that, I sincerely hope that if I am in the dentist's chair when there is a power glitch and the ISP link goes down, the equipment will reboot and continue to function without the Internet.)

The reality is that there will always be stand-alone networks or networks that are intermittently connected, and there will always be unmanaged networks, and there will be self-managing networks. You are only considering a very old-fashioned network which is designed and managed in a top-down way according to a plan. That is not everything.

SLAAC/RA remains essential as part of the big picture. It's nothing to do with one particular variant of one particular open-source o/s.

Incidentally, I think we could easily make DHCP redundant. Making SLAAC/RA redundant would be much harder.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Sep 2021 08:55:37 +1200

> But DHCP has a centralized facility for it with well-developed software and integration to DNS.

Which is a terrible defect when your network partitions. How does it work after an earthquake?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Sep 2021 10:46:26 +1200

On 23-Sep-21 01:49, Philip Homburg wrote:
> router of any kind on a subnet.

Yes, I think that was the world view in ~1994 when this conversation started.
I was thinking of SLAAC, not SLAAC+RA. SLAAC starts with link-local addresses.
Certainly, a modern version of "dentist's office" is more like a homenet with
several in-house routers. RA is what you get out of the box when you install
an IPv6 router. Then you need ULAs unless you have an active ISP.

Just to be clear, we defined IPv6 in such a way that it doesn't depend on
having an active ISP or any kind of centralised top-down configuration.
That's something we need to keep; we aren't here to support any 
particular business model such as an ISP-based Internet. (The very
concept of "CPE" assumes that business model.)

Of course, we also need the ability to add either top-down configuration via
something like DHCP, or automatic self-configuration. The latter could make
DHCP redundant. There's nothing magic about DHCP; it's just an overlay on
the basic IPv6 mechanisms if you want centralised top-down configuration.
If you don't want that, you don't want DHCP.

> Both RA and DHCP are equally irrelevant.

I remind you that we did the basic IPv6 design, including RA, before DHCP
was a thing. (Strictly speaking, it was an emerging technology.)
DHCPv6 is an add-on.

> routers announcing their own prefixes, creates interesting corner cases.

It does. Hence RFC8028 and PVDs.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Sep 2021 10:39:57 +0200

> There are many kinds of networks and many kinds of hosts, and I
> think that we are doing ourselves a disservice to try to hit them
> all with the same hammer.

A single hammer is exactly with the WG is doing. Copying features from
DHCPv6 to RA is supported, adding features to DHCPv6 that duplicate features
in RA is blocked.

The hammer for basic network configuration that is support in this WG is
RA. 

> I think that's an unfair characterization of the WG.  It does look
> that way by message count, but I think that we have some very loud
> individuals.

As far as I know this WG blocked adding a default router to DHCPv6. As far
as I know, there is still no chance a default router option for DHCPv6 
would pass. It is a feature that has been reqeusted time and time again.
And each time it has been rejected.

> I don't really know how universal-ra has anything to do with DHCP
> vs RA.  universal-ra is about being able to do experiments or other
> minor things in RA space without having to wait three years for
> your router vendor to include

The draft adds the option to both RA and DHCP.

As has been mentioned before in this discussion, there are ways to add
support for unknown RA options to routers.

The DNS community has been using such a mechanism for a long time and works
fine.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 23 Sep 2021 11:16:01 +0200

>an IPv6 router. Then you need ULAs unless you have an active ISP.

Maybe we should leave the "dentist's office" in 1994 with the original 
definition: no router at all.

Then we can have another term for a network with routers, but without a
connection to the wider internet.

>concept of "CPE" assumes that business model.)

Recently my home network is a bit unstable. Quite a few devices are
complaining that they don't have a network connection when there is no link
to the internet.

So client side, we already moved on, a 'network' implies a connection to the
internet.

As far as I can tell, there is barely any market for networks that are
not connected to the internet. Of course they exists. It is just that for
most people a network without an internet connection is a broken network.

It is good that we have the mechanisms (such as ULA) for disconnected
operation. But it's a corner case.

>If you don't want that, you don't want DHCP.

As DHCPv4 shows, DHCP works in the same environment as RA. There is nothing
particularly heavy weight, or centralised about DHCP. DHCP supports those
things, whereas RA does not. DHCP on it's own is perfectly fine for network
configuration.

With one exception: in networks where network parameters change a lot,
RA is better. In my experience, those networks are rare. Obviously, we want
to keep RA for those cases.

>was a thing. (Strictly speaking, it was an emerging technology.)

DHCPv4 was a thing before IPv6 was deployed at any scale. Even DHCPv6 was
defined before there was any significant deplyment of IPv6.

I'm not saying we should get rid of RA. It is just that there is a constant
stream of negativity to anybody who would want to use DHCPv6 configure all
network parameters of IPv6 hosts in a network.

>It does. Hence RFC8028 and PVDs.

Indeed there is RFC 8028. It is tricky to implement and very few hosts 
support it. And realistically, it only works if all hosts in a subnet support
it. It is good have, but it may take a very long time before all hosts
support it.

Each time I look at PVD, it seems to be information that could be put in
DHCP, but got a different transport and is defined in an informational RFC.

It is funny how RFC 8801 went to work around the limitations of RA. In
DCHP a host would request a particular piece of information. Section 5.2 in
RFC 8801 describes how you can send RAs from different link-local addresses
to address hosts that are PvD-aware and Non-PvD-aware. And then extra
hacks to include an RA header in the PvD-option.

It seems a rather deperate attempt to keep using the RA hammer.

I have to admit, the PvD option is sufficiently convoluted that it would
be a very good candidate to be expressed in CBOR.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 23 Sep 2021 09:43:51 +0000

Hi Brian,
Please, give an example of the network where the router is missing.
And if you would manage to find the one then why LLA would be not enough?

DHCP is not possible to make redundant - market would not agree. Technically it may be possible.
Eduard
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2021 11:54 PM
To: Vasilenko Eduard <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

Eduard,

Regards
   Brian Carpenter

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 23 Sep 2021 09:48:06 +0000

I agree that distributed system is better in theory. But it is always more complex and less secure as a result.
Earthquake (or similar) happens very rarely, but dealing with SLAAC that does not support 2 PA addresses we need much often.
IPv6 should not be for geeks, it should be for business.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, September 22, 2021 11:56 PM
To: [email-masked]
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

   Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 23 Sep 2021 09:54:36 +0000

> we defined IPv6 in such a way that it doesn't depend on having an active ISP or any kind of centralized top-down configuration.
The local DHCP server on the CPE could start leasing ULA addresses "out of the box". No dependency on others.
If an earthquake would split the apartment into 2 pieces - it would not work anyway.

DHCP has no magic. Just 2 competitive solutions (one is complex/distributed) creates a lot of excessive problems.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, September 23, 2021 1:46 AM
To: Philip Homburg <[email-masked]>; [email-masked]
Subject: Re: Adoption Call for <draft-troan-6man-universal-ra-option>

On 23-Sep-21 01:49, Philip Homburg wrote:
>> to do, what we called "the dentist's office scenario" in the early 
>> days of IPn g design, actually modelled mainly on Appletalk. You can 
>> hook a few IPv6 boxes together on a wire and they will start talking 
>> to each other using SLAAC and link-local addresses. Add a router with 
>> a prefix and they will start talking t o the world using SLAAC and 
>> RA. DHCPv6 is completely unnecessary until the net work reaches a certain level of complexity.
> 
> As far as I know, the "the dentist's office scenario" is when there is 
> no router of any kind on a subnet.

Yes, I think that was the world view in ~1994 when this conversation started.
I was thinking of SLAAC, not SLAAC+RA. SLAAC starts with link-local addresses.
Certainly, a modern version of "dentist's office" is more like a homenet with several in-house routers. RA is what you get out of the box when you install an IPv6 router. Then you need ULAs unless you have an active ISP.

Just to be clear, we defined IPv6 in such a way that it doesn't depend on having an active ISP or any kind of centralised top-down configuration.
That's something we need to keep; we aren't here to support any particular business model such as an ISP-based Internet. (The very concept of "CPE" assumes that business model.)

Of course, we also need the ability to add either top-down configuration via something like DHCP, or automatic self-configuration. The latter could make DHCP redundant. There's nothing magic about DHCP; it's just an overlay on the basic IPv6 mechanisms if you want centralised top-down configuration.
If you don't want that, you don't want DHCP.

> That scenario seems completely unrelated to this discussion. Basically 
> the support we have for the "the dentist's office scenario" is that 
> hosts automatically configure a link-local address. Nothing more nothing less.
> 
> As the current IPv4 network shows, even the smallest networks work 
> fine with DHCP. DHCP in modern CPEs is completely automatic. So the 
> notion that a small network would need something like RA is rather weird.

I remind you that we did the basic IPv6 design, including RA, before DHCP was a thing. (Strictly speaking, it was an emerging technology.)
DHCPv6 is an add-on.

> Where RA goes beyond DHCP is in supporting multiple default routers. 
> Which is no longer a small, simple network. And in my experience, 
> having multiple routers announcing their own prefixes, creates interesting corner cases.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Sep 2021 09:22:22 +1200

> Please, give an example of the network where the router is missing.

It's sufficient that the ISP link is down. In that case any source
of external config is missing, so all DHCPv6 can provide is default
info, which RA does perfectly well.

> And if you would manage to find the one then why LLA would be not enough?

Well, one reason is that local browser activity becomes impossible (see
draft-carpenter-6man-rfc6874bis), whereas browsers work perfectly well
with ULA. But yes, that is precisely the argument for the LL part of SLAAC.

> DHCP is not possible to make redundant - market would not agree. Technically it may be possible.

Indeed. I don't seriously propose that; it's an academic observation about
the difference in nature between SLAAC/RA and DHCPv6.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Sep 2021 10:11:14 +1200

> IPv6 should not be for geeks, it should be for business.

No, it is (like the Internet) for everybody. So while business scenarios need to be satisfied, so do all other possible scenarios. Earthquake recovery is only one example of why we need robustness under unpredictable disasters.

Regards
   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Sep 2021 10:42:57 +1200

> connection to the wider internet.

I'm pretty sure that scenario was considered by HOMENET, and it's certainly
one we've considered (at least during network construction) in ANIMA.

> So client side, we already moved on, a 'network' implies a connection to the

And that's something we need to fix. I was very disturbed when I acquired
a new TV that its first demand was that I should create an account with
$MANUFACTURER before I could continue the setup. This may be current
reality, but it isn't OK.
 
> most people a network without an internet connection is a broken network.

Of course. But that doesn't (or shouldn't) apply to IoT deployments or
any situation where an air gap is a basic security environment.
> operation. But it's a corner case.

It is for today's mainstream business model.

> to keep RA for those cases.

Right. But as I just said, your argument applies to today's mainstream
business model.

> defined before there was any significant deplyment of IPv6.

That's true. I was talking about when the basic design decisions were
taken. As with any technology, those are very hard to change.

> network parameters of IPv6 hosts in a network.

Because of a business model tussle, perhaps? Not the only example of that
in IETF history.

> be a very good candidate to be expressed in CBOR.

I agree with all you say about PVDs. RFC8028 would have happened about
5 years earlier if I hadn't hoped that MIF would find a neat solution.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 23 Sep 2021 22:24:32 -0700

Brian,

one comment below.

> On Sep 23, 2021, at 3:42 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I have two shipping products on my home network that use ULAs (for different purposes as far as I can tell), my Eero routers and my Apple TV.   It’s now in widespread usage.

Bob

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Sep 2021 16:24:19 +1000

On Fri, 24 Sep 2021, 15:25 Bob Hinden, <[email-masked]> wrote:

> I have two shipping products on my home network that use ULAs (for
> different purposes as far as I can tell), my Eero routers and my Apple TV.
>  It’s now in widespread usage.
>

Here in Victoria, Australia, there are 4 electricity smartmeter networks
with a total of about 2.4 million meters attached, all using IPv6 only and
all addressed out of the ULA address space.

The smartmeters don't have access to the Internet. It's ULAs to one side of
the management systems, and IPv4 on the other facing the corporate network.

Far from a corner case. Just not visible outside of that industry.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Sep 2021 13:22:07 +0200

>reality, but it isn't OK.

I fully agree that a TV should work without any network connection. Though
I'm not sure what the IETF can do about that.

>any situation where an air gap is a basic security environment.

As far as I can tell, most IoT devices are connected to the internet. Of
course, I prefer IoT device communication to stay within my network. Again
not something the IETF has a lot of influence on.

>It is for today's mainstream business model.

I don't see why that business model would change. Maybe in areas where
network outages are common.

>Right. But as I just said, your argument applies to today's mainstream

It seems right to me to support the mainstream business model first and then
deal with other cases. A lot of RA discussions are about rare cases and
solutions come at the expense of the common case. I understand the
engineering desire to handle all cases. But it can lead to overly 
complex solutions that are not a good fit for the common case.

>taken. As with any technology, those are very hard to change.

They are hard to change because people here have actively resisted change for
a very long time. And the change requested is not about taking away
something. It is just adding a bit more support for DHCPv6 in some places.

>Because of a business model tussle, perhaps? Not the only example of that

I don't see the business advantage in blocking DHCP. Nobody seems to gain
here. Unless the business model is about keeping IPv4 alive as long as
possible. 

>5 years earlier if I hadn't hoped that MIF would find a neat solution.

I don't know what MIF was supposed to do in this area (multiple upstreams).
I thought MIF was about hosts having multiple interfaces.

It seems to me that multiple upstream problem is something for homenet.

For many years now I have been running with multiple upstreams on
different routers transparant to hosts. This works perfectly fine with 
existing hosts as long as the routers know about each other and each other's
prefixes. Which is where homenet comes in.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Sep 2021 13:35:09 +0200

>Far from a corner case. Just not visible outside of that industry.

I seems to me that with 2.4 million devices, it is quite possible to ask
a RIR for some addresses. Of course, perfectly fine that ULA works as well.

I assume that each smartmeter gets a default route. So for the meter,
it is as if the meter is connected to the internet.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Sep 2021 09:11:22 +1200

> I'm not sure what the IETF can do about that.

What we *can* do is make sure that nothing in our mandatory-to-implement
set requires such a connection.

> not something the IETF has a lot of influence on.

Again, we can avoid *requiring* WAN connectivity. (Therefore, depending
on DNS is not always a good thing, but that is a bit off topic.)
 
> network outages are common.

Or where disaster planning is a thing. Of course, ULAs may not always be
the answer, but "will I have an address after an earthquake?" is a
question worth asking.
 
> complex solutions that are not a good fit for the common case.

Fair comment. But IMHO it's the IETF's job to ensure that the bare minimum
set of standards covers all cases, not just the common cases.
 
> something. It is just adding a bit more support for DHCPv6 in some places.

Maybe formulating that request in a well-argued draft would be helpful?

> It seems to me that multiple upstream problem is something for homenet.

I don't think the two problems can really be separated, and multiple
upstreams definitely affect enterprise networks too.

> prefixes. Which is where homenet comes in.

Doesn't that add an extra hop when a packet gets to the "wrong" exit router?

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Mon, 27 Sep 2021 19:00:53 +0200

>set requires such a connection.

Indeed. Though it seems to me that RFCs are in relatively good shape in this
area. I don't think there is anything mandatory that would fail with
disconnected operation.

>on DNS is not always a good thing, but that is a bit off topic.)

I don't know where we (the IETF) are requiring WAN connectivity.

>the answer, but "will I have an address after an earthquake?" is a

I guess this depends on lot on where you are. Where I live, a disaster
that kill network connectivity is likely to kill power as well. Not much
network without power.

Of course, some organisations have backup power. But in those cases,
why bother with ULA. Just get a static prefix and configure that in
all onsite routers.

For home use, we see that many games require internet connectivity even if
the game itself doesn't require a server.

In the past, people had their own media collections. These days, everything
is streamed.

So yes, you may be able to print. And with a bit of luck you can check
your internet connected fridge. But not much else is likely to work without
an internet connection.

>Maybe formulating that request in a well-argued draft would be helpful?

I doubt it. 

>upstreams definitely affect enterprise networks too.

It seems to me that multiple interfaces brings problems that you typically
don't find in a network with multiple upstream (certainly not in a managed
entrerprise network).

Multiple interfaces often requires a host to deal with a cost problem:
typically wifi is cheaper than mobile data (or at most as expensive). When
do you use mobile data? Multiple interfaces bring a split universe. Maybe
a DNS lookup on one interface needs to be paired with a connection on
that same interface. Each interface may have its own DNS resolvers, etc.

A host on a network with multiple upstreams can and should rely on 
the routers telling the host what to do. 

>Doesn't that add an extra hop when a packet gets to the "wrong" exit router?

Yes. But with redirects, only the first packet that goes to a particular 
destination. In theory, a host can pick a source address from a different
prefix for each flow that it creates to a single destination. Then
many packets may end up at the wrong router. In that case it is best if the
host also records the source address in the destination cache.