Subject: Re: [v6ops] sidetrack on DNS-SD vs. DHCP

From: Philip Homburg <[email-masked]>
Date: Wed, 01 Feb 2017 12:16:23 +0100

In your letter dated Wed, 1 Feb 2017 08:23:05 +1300 you wrote:
>On 01/02/2017 07:36, Philip Homburg wrote:
>...
>> So realistically, every environment should run both RA and DHCP[v6].
>
>It seems to me that there are plenty of running proofs that this
>is not true.

What I see is that in plenty of cases, a host gets quite a few more parameters
from DHCPv4 than from IPv6 equivalents.

If you know a write up of a largish organisation that is IPv6-only and
doesn't use DHCPv6 anywhere, then I'd like to know.

Did they ever provide hosts with hostnames and what do they do now?

For example, did they ever use PXE boot and what do they use now?

Do they run ntp servers in house and if so, how do they inform hosts about
them?

I seem to remember that Windows put some parameters in DHCP, but maybe that's
thing of the past.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Feb 2017 08:06:49 +1300

> doesn't use DHCPv6 anywhere, then I'd like to know.

I don't. But then, I think that being IPv6-only is not very appealing
for the next ten or twenty years. Of course, I've been a true believer in
dual stacks since 1994.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Feb 2017 11:10:07 -0800

I have asked Xing Li about CERNET2. CERNET2 has been IPv6-only since 2008 or thereabouts, and posted a blog on its upcoming planned expansion to 1200+ universities at https://blog.apnic.net/2017/01/31/chinas-first-ipv6-backbone-network-connect-1200-campuses/. 

> On Feb 1, 2017, at 11:06 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Feb 2017 08:12:05 +1100

On 1 February 2017 at 05:36, Philip Homburg <[email-masked]>
wrote:
>>* Unnecessarily increasing the attack surface: two protocols, two pieces
>>of code -- not to mention protecting both, if you happen to care.
>
> I'm not sure this is correct.
>
> At the moment you always need RA. Of course, if somebody just goes ahead
> and does a default router option in DHCPv6, RA could go away, but that is
> not the case at the moment.
>
> Unless we duplicate lots of DHCP options in RA, you probably need DHCP
> as well, for example to specify NTP servers.
>
> So realistically, every environment should run both RA and DHCP.
>
> Ideally, all hosts should support getting address both using SLAAC and
> using IA_NA, so hosts have to deal with the attack surface as well.
>
> Migrating to just RA will at some point replicate statefull DHCPv6 in RA,
> so that's certainly not ideal.
>
> Getting rid of RA is realively easy (that how IPv4 works) but will not be
> popular.
>
> So the dual attack surface seems something we just have to live with.
>

I think whether or not one protocol is the right number depends on the type
and number of problems to solve, and the best place to solve them (when
there are a number of possible places).

I think the problem space for hosts is:

- Internet layer interface specific IPv6 protocol configuration (e.g.,
addressing, default router, ND params.)
- Internet layer protocol general or non-interface specific host
configuration
- Application layer service discovery
- Application layer service client configuration

In IPv4, all of these problems are primarily solved with DHCPv4, even
though there are a number of dissimilar problems.

I think IPv6 provided the opportunity to have another go at solving these
problems separately where useful and where they could be better and more
reliably solved.

For example, I think it makes sense to have an on-link authoritative device
provide link specific IPv6 protocol parameters to hosts, as the problem and
the parameters are local to the individual link. (RAs are perhaps a bit
misnamed - they're advertisements from a router that advertise link
configuration parameters, which may include the router offering itself as a
default router, rather than just an advertisement of the router itself.
Link Configuration Advertisements might have been a better name.)

Regards,
Mark.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 1 Feb 2017 22:34:29 +0100

Hi Mark,

> I think whether or not one protocol is the right number depends on the type and number of problems to solve, and the best place to solve them (when there are a number of possible places).
> 
> - Internet layer interface specific IPv6 protocol configuration (e.g., addressing, default router, ND params.)
> - Internet layer protocol general or non-interface specific host configuration
> In IPv4, all of these problems are primarily solved with DHCPv4, even though there are a number of dissimilar problems.
> 
> I think IPv6 provided the opportunity to have another go at solving these problems separately where useful and where they could be better and more reliably solved.

Thank you, this way of looking at the combination of requirements makes sense.

There should be an architecture RFC about this stuff :)
Sander

---

From: Mark Smith <[email-masked]>
Date: Thu, 2 Feb 2017 10:42:18 +1100

On 2 Feb. 2017 8:34 am, "Sander Steffann" <[email-masked]> wrote:

Hi Mark,

> I think whether or not one protocol is the right number depends on the
type and number of problems to solve, and the best place to solve them
(when there are a number of possible places).
configuration

Thank you, this way of looking at the combination of requirements makes
sense.

RFC1958 and RFC5505 cover these sorts of architectural topics. There is
also a bit of architecture discussion at the start of RFC1122.

Regards,
Mark.

Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Feb 2017 13:43:39 +1300

...
> also a bit of architecture discussion at the start of RFC1122.

The thing is, we are talking here about fixing up a confusion created by
our own history -- the fact that DHCP was immature technology when IPv6
was designed, so including a stand-alone autoconfiguration mechanism was,
truly, a great step forward. So now that DHCP(v4) is a great success,
and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do.

That certainly isn't what the editor of RFC1958 had in mind. I can't
speak for RFC5505.

    Brian

---

From: [email-masked]
Date: Thu, 2 Feb 2017 10:22:58 +0100

> and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do.

Fate sharing was one of the major objections to DHCP.
It was I think also felt that a service discovery mechanism was the correct way of resolving many of these issues.

Only DNS recursive resolvers in addition to addressing was required from the network.
(Now I'm even less certain that DNS recursive resolvers should be configured by the network, but oh well).

Another data point on history here is from:
https://www.ietf.org/proceedings/52/141.htm

Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms
--------------------------------------------------------

<draft-droms-dnsconfig-dhcpv6-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Questions about some of the assertions in the intro, asking to clarify some of the statements.

Nordmark: Cost benefit tradeoffs. Steve points out that without state sharing problem is an improvement. Is this enough of an advantage to be worth the trouble of deploying? Deering agrees. The real question for the w.g. do we need anything beyond DHCP for client configuration?

Soliman: Thinks being able to do discovery and configuration without DHCP servers is good. Has always been a goal of the w.g. Thinks fate sharing is a significant issue with DHCP and other server approaches. Thinks claim that DHCP server can be combined in same box may not be enough. Need to have discovery mechanism in same function (process) as the service. Thinks this is a very important and DHCP doesn't meet this requirement.

Austein: Disagrees about the fate sharing comments. Could put DHCP in same process. It is an implementation issue. Doesn't see that anycast helps with the fate sharing. DHCP approach is better in the long term because it handles other information. DNS is staring to have a dependency on NTP. Doesn't want to define a special configuration mechanisms for every service. Thinks DHCP is a better solution.

Zill: If you send out one of the DHCP information requests. Will one server know all? Narten: Not a problem that you learn an incorrect list of servers.

Suggestion that level 1 compliance is OK. Could use DHCP for level 2.

Huitema: Thinks original requirement as stated by Steve Deering is correct. Limited fate sharing is better approach. Thinks we need a simple solution that work in simple networks. Thinks this DNS discovery approach provides more flexibility the just using DHCP server.

Nordmark: What is the extensibility in each approach? Talking about these as one thing is part of the problem. Could separate anycast to reach server from getting service information.

Deering took poll of room: How many people think w.g. should continue work on stateless DNS discovery? Consensus to continue work.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 06:44:08 -0300

> not the case at the moment.

Agree with this.

[...]
> So the dual attack surface seems something we just have to live with. 

Yes. But that doesn't make it a nice outcome. :-)

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 2 Feb 2017 09:40:34 -0500

> Yes. But that doesn't make it a nice outcome. :-)

There's a pretty easy fix: make sure that your vendor supports the rdnss option in RA.   If they don't, ask them to fix the problem.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 02 Feb 2017 15:56:30 +0100

>and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do.

In my recollection, IPv6 SLAAC is a departure from how IPv4 ever worked.
Before DHCPv4, RARP was commonly used on ethernet. And ppp had its own way
of providing hosts with addresses.

For some environments, SLAAC is obviously a step forward. However, many
implementations mistakenly assumed that not implementing DHCPv6 IA_NA was OK.
And we never managed to create a strong encouragement to implement it.

Worse, not implementing DHCPv6 became so fashionable that long after DHCPv4
became completely standard for IPv4, we added the RDNSS options to RA.

And when it is clear that operators use the DHCPv4 default router option in
ways that simply cannot be supported by RA, this use case is actively 
suppressed by not standardizing a default route option in DHCPv6.

The thing that I think is worst is actively breaking things. It is safe
to assume that some extremely limited devices cannot implement both SLAAC
and stateful DHCPv6. However, the devices that mostly common cause problems
by not supporting IA_NA do so for political reasons. The same goes for
the DHCPv6 default route. Technically not hard to implement, but rejected
none the less.

---

From: Mark Smith <[email-masked]>
Date: Fri, 3 Feb 2017 06:57:20 +1100

> of providing hosts with addresses.

So I started working with IP in around 1991, and here is what I remember.

Firstly, this was before DHCPv4. For automated address configuration,
BOOTP was being used. BOOTP is a simplified version of DHCPv4 (or
rather, DHCPv4 is (literally) a more complicated version of BOOTP),
which doesn't have pools of addresses or lease times. The BOOTP server
has a list of link layer addresses and the corresponding configuration
information. It is centralised static configuration, DHCPv4 added
dynamic allocation and a new name for BOOTP.

BOOTP was developed to overcome RARP's limitations (from the RFC951)

" However RARP had the disadvantage
   that it was a hardware link level protocol (not IP/UDP based).  This
   means that RARP could only be implemented on hosts containing special
   kernel or driver modifications to access these 'raw' packets.  Since
   there are many network kernels existent now, with each source
   maintained by different organizations, a boot protocol that does not
   require kernel modifications is a decided advantage."

My focus was desktops at the time, and the IP stack we were installing
on them didn't support BOOTP, so manual address configuration was the
way IP addressing was handled for them.

PPP was also in development at the time, and SLIP was the way people
were doing dial up IP.

The first networking protocol I learnt about and worked with was IPX,
IPv4 was second. IPX was so much simpler than IPv4 to learn and
understand (no subnets, subnet masks and classes, IPX has fixed length
network and host/interface address fields).

I started teaching IPv4 a few years later, and given how complex IPv4
was in comparison to IPX, I was curious why. One of the things I've
come across is how addressing and address resolution looks to have
been performed prior to ARP and Ethernet. From RFC796, "ADDRESS
MAPPINGS"

"Internet to Local Net Address Mappings
--------------------------------------

   The following transformations are used to convert internet addresses
   to local net addresses and vice versa:"

I think we'd describe the original ARPAnet protocol as a link-layer
protocol today. Here's how ARPAnet addresses were mapped to IPv4 host
addresses:

 ARPANET
      -------

         The ARPANET (with 96 bit leaders) has 24 bit addresses.  The 24
         bits are assigned to host, logical host, and IMP leader fields
         as illustrated below.  These 24 bit addresses are used directly
         for the 24 bit local address of the internet address.  However,
         the ARPANET IMPs do not yet support this form of logical
         addressing so the logical host field is set to zero in the
         leader.

         The network number of the ARPANET is 10 (Class A).

         +--------+--------+--------+
         |  HOST  |  ZERO  |  IMP   |   ARPANET
         +--------+--------+--------+
              8        8        8

         +--------+--------+--------+--------+
         |   10   |  HOST  |   LH   |  IMP   |   IP
         +--------+--------+--------+--------+

So in that regard, the original IPv4 addressing model was the same or
similar to IPX's - embed the node link-layer address in the IPv4
address, and use that information directly to send to the node, rather
than having an address resolution protocol. SLAACs almost obsolete
current model of using link-layer addresses to generate IPv6 IID is
closer to the original IPv4 addressing model (and IPX's) than the
DHPv4's pool allocation model.

Ethernet addresses were too big to do this sort of mapping with, and
the above is also network number specific. So ARP was developed. This
also explains why the ARP RFC has an RFC number in the 800s, a number
of years after IP was developed and deployed.

> suppressed by not standardizing a default route option in DHCPv6.

I think the trouble with this view is that they only think that RAs
are being used to advertise a router as a default gateway.

RAs do a lot more than that - announce prefixes for SLAAC, announce
whether the prefix is on-link or off-link, announce parameters related
to mobile IP, announce ND parameters hosts are to use, announce the
IPv6 layer MTU. All of that can be announced in an RA without the
router being considered a default router (the router lifetime field
value would be zero in this case.). RAs are an advertisement from a
router rather than an advertisement just for a default router.

This is not to say that all couldn't be ported across to DHCPv6.
However, it is important that people realise that RAs aren't just
announcing a default router, and that therefore eliminating RAs would
not be as simple as creating a DHCPv6 default router option.

> by not supporting IA_NA do so for political reasons.

Stateful DHCPv6 is optional, SLAAC is mandatory, and therefore the
support for SLAAC is universal and ubiquitous.The decision to support
an optional protocol when there is a functionally equivalent mandatory
protocol is not a political decision, it is a technical and
operational one.

> The same goes for

Rejected because DHCPv6 is the wrong place to reliably and accurately
solve a link-specific parameter advertisement problem.

IPv4 and it's models have worked and been successful, however is a
long way from the pinnacle of layer 3 protocol design. Other layer 3
protocols have done things differently and better than IPv4, and IPv6
has adopted some of those ideas instead.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 13:06:14 -0300

On 02/02/2017 11:40 AM, Ted Lemon wrote:
> On Feb 2, 2017, at 4:44 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> There's a pretty easy fix: make sure that your vendor supports the rdnss
> option in RA.   If they don't, ask them to fix the problem.

I'm not a MS Windows user. Besides, the same can be said for android,
and IIRC there's a bug report for that, and didn't work out, either.

Probably we could help a bit in tis area, so that people submitting bug
reports have something to point vendors at (not that they don't about
the issue).

Thanks,