Subject: IPv6 automatic configuration architecture (?)

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 00:43:10 +0200

Folks,

This note has been triggered by the ipv6-only flag discussion, but I'd
say the corresponding discussion spans more than just this I-D.

Whenever there has been a proposal or discussion about a DHCPv6 option
to advertise a default route, the argument has been, IIRC/AFAICT, that
the DHCPv6 server is not in a position to tell where packets should be
sent to.

In the context of the discussion about the ipv6-only flag, there is an
implicit assumption that a router (possibly a single router), can speak
for the network (whether the network is v6-only or not).

I'm wondering what's the model/architecture here. Specifically, why e.g.
an IPv6 router could speak for the whole subnet about IPv4 connectivity,
but OTOH a DHCPv6 server cannot e.g. advice where packets should be
directed to.

FWIW, this is not meant as an argument about ipv6-only, but rather to
try to make sense out of slaac/dhcpv6 as two components of IPv6
automatic configuration -- hopefully helping ourselves what to pursue
and what not, and others to figure out how the pieces fit together.

An, disclamer: I'm not a fan of any specific automatic control
mechanism. I do care about us having a rationale about how all these
pieces fit together, and about the partial overlaps we have among
slaac/dhcpv6.

Thanks!

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Oct 2018 10:43:41 +1100

Hi Fernando,

> but OTOH a DHCPv6 server cannot e.g. advice where packets should be

Other than the DNS RA options, all other parameters conveyed by RAs
are specific to and limited to the link the RA is sent on, and are
limited to being layer 3 functional and operational parameters.

A router directly attached to a link is going to be a better authority
for those link specific layer 3 parameters than a potentially remote
DHCPv6 server. The IPv6 only status or not of a link is a link
specific parameter, so I think carrying it in RAs would better suit
the model.

RAs are probably misnamed (their name has probably come from their
IPv4 ancestor in RFC1256). "Router Advertisement" sounds like it's
only an advertisement about a router. "Advertisement from a Router"
might be more accurate, because it is carrying information about more
than just the router sending it e.g. PIOs are not unique to a router
announcing them in an RA it sends.

Even then, a device doesn't really have to be a router to send an RA.
For example, an RA with a zero router lifetime is not announcing a
router, yet is still conveying link specific parameters. I can think
of some scenarios where having a host on a link announce these sorts
of RAs would be the case.

So perhaps an even more accurate name for RAs would be something like
"IPv6 Link Configuration Advertisements", where the IPv6 link specific
configuration includes learning of default routers on the link. Even
if renamed, "IPv6 Link Configuration Advertisements" would still
logically be sent most of the time by routers on the link.

> and what not, and others to figure out how the pieces fit together.

I put some thoughts down about Internet transparency and application
configuration, and what should be used for which in this draft (I
don't think RAs should carry DNS options for example):

"IPv6 CE Device DHCPv6 Option Transparency"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00

specifically section 2:

"Internet Transparency and Application Configuration"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 02:04:26 +0200

> limited to being layer 3 functional and operational parameters.

They seem to be ore related to the up-link that to the link where the
packet was sent. eg., a PIO or RIO has more to do with the upstream,
than with the subnet. If you sent your packets to the wrong router, they
might get blackholed.

> specific parameter, so I think carrying it in RAs would better suit

Is it? One router provides IPv6-only, another IPv4-only, and a third one
dual-stack. Why should the first one speak for the three of them?

> of RAs would be the case.

? A device that sends an RA with a default lifetime of 0 seems to be a
router to me. You just shouldn't use it as a default router.

> don't think RAs should carry DNS options for example):

Well, the DNS option thing is closely related with my original
questions. It seems to be that there isn't much of clear rationale
regarding what goes where, other than "we should be able to do all basic
configuration with RAs"... (for some meaning of "basic")

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Oct 2018 11:56:07 +1100

Hi Fernando,

Unfortunately I can't afford to spend any more time on the IPv6 only
flag topic.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2018 14:39:37 +1300

Fernando,

> for the network (whether the network is v6-only or not).

Not quite right. There is an *explicit* requirement that the flag be set
in *all* IPv6 default routers on the link by a human, who is presumed
to have decided that the link is v6-only.

> I'm wondering what's the model/architecture here.

That a human decides, and configures *all* IPv6 routers accordingly. (Those
opposed to the proposal have, I think, a similar model: a human decides,
and configures *all* L2 switches accordingly.)

More generally, isn't the model that basic connectivity can be realised
using ND+RA, and DHCPv6 is an add-on?

(For IPv4, basic connectivity could be realised by manual configuration,
and DHCP was an add-on. At least, that is the historical story.)

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2018 14:51:49 +1300

Fernando,
> dual-stack. Why should the first one speak for the three of them?

If you're talking about the proposed IPv6-only flag, IT DOESN'T. (Sorry
to shout but this is so fundamental.)

A link on which you have an IPv4 router and on which an IPv6-only
router sets the IPv6-only flag is simply misconfigured. It doesn't
really matter in your example, because the dual stack router will not
set the IPv6-only flag, and therefore the hosts will not register
the flag as set, as specified in the draft.
 
>> of RAs would be the case.> 

And the IPv6-only flag is defined as only meaningful when sent by
an IPv6 default router, so it simply doesn't matter if a non-default
router sends it - it's a no-op.

I really believe we covered all these cases in the draft.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2018 19:26:11 +0200

> to have decided that the link is v6-only.

Can't the same be argued about the setting of a default route in DHCPv6?
Or, put another way: what's the argument against a DHCPv6 option to
carry a default route?

> and configures *all* L2 switches accordingly.)

FWIW, while my question was triggered in this case as a result of the
ipv6-only flag it wasn't meant about the ipv6-flag itsef.

> using ND+RA, and DHCPv6 is an add-on?

That's exactly what I'm wondering (what the model is). And the more and
more we stuff into SLAAC (essentially, some for of prefix delegation,
etc.), I have not much of an idea what the model is. I find it harder
and harder to find a rationale for what we currently have.

FWIW, what would be the definition of "basic connectivity"? Address,
default route and DNS server? If "yes", I guess RDNSS would have been
specified way before. If "not" (basic connectivity being just address
and default route) then e.g. RDNSS shouldn't be there. One might also
argue that RIOs, while useful, are a bit outside of *basic* connectivity?

Thanks,

---

From: Simon Hobson <[email-masked]>
Date: Tue, 23 Oct 2018 21:02:42 +0100

> the DHCPv6 server is not in a position to tell where packets should be

ISTM that the main reasons coming up from time to time are :

1) DHCP isn't conducive to rapid reconfiguration of networks - eg for a mobile device which gets a new address as it moves around and gets a new connection. For this reason, one large vendor of a mobile OS has decreed that "though shalt not do DHCPv6".
I can understand why not use DHCP for such setups, but many of us have highly stable landline connections and this issue isn't a problem for us - but it seems that we shouldn't be allowed to configure our networks with DHCP because of the mobile issue.

2) Servers and Networks are frequently different departments, and it seems to be argued that these two departments don't talk to each other, and hence it makes no sense to allow any network configuration by the servers team. But given that both teams **must** talk to each other (server addresses, DNS entries, and network configuration have to match for things to work) - I think this is a bit of a red herring. So no, I don't think it is logically valid to say that the DHCP server can't know where packets must be sent to - and conversely using RAs means that even on a stable network, means that hosts have a dynamic environment where routes are dependent on "broadcasts" which do not have guaranteed delivery.

3) DHCP implies central management and that goes against the idea of privacy. Hosts should be allowed to pick their own addresses and change them regularly - but that's not automatically incompatible with using DHCP.

> Specifically, why e.g. an IPv6 router could speak for the whole subnet about IPv4 connectivity, but OTOH a DHCPv6 server cannot e.g. advice where packets should be directed to.

Apart from the issue already mentioned that **all** IPv6 routers must set the flag for it to have effect, you are correct to question it since IMO a DHCP server can speak for the whole network segment - barring misconfiguration, a DHCP server **is** authoritative for a network whether locally connected or remote.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Oct 2018 01:05:54 +0200

On 10/23/18 10:02 PM, Simon Hobson wrote:
>> Whenever there has been a proposal or discussion about a DHCPv6
>> option to advertise a default route, the argument has been,
>> IIRC/AFAICT, that the DHCPv6 server is not in a position to tell
>> where packets should be sent to.
> 
> 1) DHCP isn't conducive to rapid reconfiguration of networks - eg for
> a mobile device which gets a new address as it moves around and gets
> a new connection. 

Doesn't IPv6 have "recoonfigure"?

> For this reason, one large vendor of a mobile OS
> has decreed that "though shalt not do DHCPv6". I can understand why
> not use DHCP for such setups, but many of us have highly stable
> landline connections and this issue isn't a problem for us - but it
> seems that we shouldn't be allowed to configure our networks with
> DHCP because of the mobile issue.

What do they use for IPv4? And, is what they use for IPv4 that different
from DHCPv6?

> 2) Servers and Networks are frequently different departments, and it
> seems to be argued that these two departments don't talk to each
> other, and hence it makes no sense to allow any network configuration
> by the servers team. But given that both teams **must** talk to each
> other (server addresses, DNS entries, and network configuration have
> to match for things to work) - I think this is a bit of a red
> herring. So no, I don't think it is logically valid to say that the
> DHCP server can't know where packets must be sent to - and conversely
> using RAs means that even on a stable network, means that hosts have
> a dynamic environment where routes are dependent on "broadcasts"
> which do not have guaranteed delivery.

+1

> 3) DHCP implies central management and that goes against the idea of
> privacy. Hosts should be allowed to pick their own addresses and
> change them regularly - but that's not automatically incompatible
> with using DHCP.

To a large extent, one is at the mercy of the local subnet. If one cares
about privacy, one randomizes the IDs one sends to the DHCPv6 server,
and pretends to be a different client -- Problem solved.  OTOH, a local
router might be advertising a given prefix only to you, and no matter
how you pick your addresses, you are toast.

So I don't buy this argument, either.

>> Specifically, why e.g. an IPv6 router could speak for the whole
>> subnet about IPv4 connectivity, but OTOH a DHCPv6 server cannot
>> e.g. advice where packets should be directed to.
> 
> Apart from the issue already mentioned that **all** IPv6 routers must
> set the flag for it to have effect, you are correct to question it
> since IMO a DHCP server can speak for the whole network segment -
> barring misconfiguration, a DHCP server **is** authoritative for a
> network whether locally connected or remote.

It would sort of seem to me that a DHCPv6 server is probably even in a
better position than a SLAAC router regarding what the network supports,
and what it doesn't.

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Oct 2018 08:31:06 +0200

Guys,

Could we stop the DHCP vs SLAAC debate please?

Ole

> On 24 Oct 2018, at 01:05, Fernando Gont <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Oct 2018 15:52:17 +0900

> What do they use for IPv4? And, is what they use for IPv4 that different

NAT

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 11:21:30 +0200

Le 23/10/2018 à 22:02, Simon Hobson a écrit :
> 1) DHCP isn't conducive to rapid reconfiguration of networks - eg
> for a mobile device which gets a new address as it moves around and
> gets a new connection. For this reason, one large vendor of a mobile
> OS has decreed that "though shalt not do DHCPv6". I can understand
> why not use DHCP for such setups, but many of us have highly stable 

Rant:

The too long latency experienced by end-users of DHCP is (more
precisely: was, at a time) a problem on the mobile device, not on the
server.  The problem was in the too long timers expecting responses, on
some implementation.

The same problem of timers is also for WiFi association operations.
They have same semantics as DHCP (and different than RA): client sends
request and waits for response.

Yet that same large vendor does not forbid the WiFi association
operations, because there is no RA-like semantics for WiFi association
that could speed things up.

I would rather say that some people at a large vendor think they
understand the problem, and come up with a wrong conclusion.

But I do not blame particular people neither particular vendors.  It is
very common at IETF to say 'DHCP is slow, dont do it'.  The problem
itself was further grasped by some WGs, showing even larger
misunderstanding.  RFCs were produced, and not yet deployed.

Alex

> other, and hence it makes no sense to allow any network
> configuration by the servers team. But given that both teams **must**
> talk to each other (server addresses, DNS entries, and network
> configuration have to match for things to work) - I think this is a
> bit of a red herring. So no, I don't think it is logically valid to
> say that the DHCP server can't know where packets must be sent to -
> and conversely using RAs means that even on a stable network, means
> that hosts have a dynamic environment where routes are dependent on
> "broadcasts" which do not have guaranteed delivery.
> 
> Apart from the issue already mentioned that **all** IPv6 routers
> must set the flag for it to have effect, you are correct to question
> it since IMO a DHCP server can speak for the whole network segment - 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6