Subject: Re: [v6ops] Making RDNSS a MUST?

From: Mark Smith <[email-masked]>
Date: Mon, 3 Apr 2017 20:10:04 +1000

On 3 April 2017 at 08:35, Doug Barton <[email-masked]> wrote:
<snip>
>
> I never said, "Everyone wants to do, or is doing, DHCP." My argument is that
> in ENTERPRISE networks, where the vast majority of dollars are spent, and
> where the largest numbers of hosts are under management, the operators have
> spoken overwhelmingly in favor of DHCP.
>

I don't think you can make that assertion if you're making it about
IPv4 and extrapolating it to IPv6.

The choice people were making was much simpler than that. It was a
choice between:

(a) manually configured static addresses

(b) automated configured addresses

and it only really became a choice when PC operating systems gained a
DHCP client - BOOTP would have been a previous choice, however IP
stacks and bootp clients on PCs were rare or non-existent at the time
(~1994 IIRC).

That is not a choice or preference of DHCP. Consequently there was no
technical evaluation of or preference for DHCP; DHCP is what you had
to use if (b) was your goal.

I doubt people are not deploying IPv6 in Enterprises because DHCPv6
doesn't support default gateways. Very few enterprises have a business
need to deploy IPv6, because it isn't solving for them a problem that
IPv4 isn't already or can't be used to solve.

Technology needs to make or save a business money. If you can't
identify how a technology you want to deploy can do either of those
things for the business, then there isn't a business need for the
technology, and the money people won't sign the Purchase Orders for
it.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 12:27:13 +0200 (CEST)

> IPv4 isn't already or can't be used to solve.

I have talked to several. They have built operational practices around how 
IPv4 happened to evolve, and if you show them IPv6 then they'll try to 
hammer that into being as close carbon-copy of IPv4 as possible so they 
don't have to change the way they run things. I don't know what they end 
up doing in the long run, but I've seen many times where people will take 
whatever IPv4 design they had and try to cram in IPv6 into it with as 
little change as possible. I also have stated that they won't deploy IPv6 
until Android gains IA_NA capability. "my network my rules".

"We do client tracking via DHCPv4 address leases, so we need to do that in 
IPv6 as well". "Do you have SAVI on your switches?" "no" "then your 
tracking is not guaranteed" "it's good enough for $RULEMAKER".

I have spent considerable time with people trying to convince them there 
are other ways to do what they need to do. At least the initial reaction 
is always "NOOOOOOOO", I don't know what the end result is.

Just to be clear, I don't think it's a good idea to cripple IPv6 just so 
that people can make it look like IPv4 to suit their current operational 
practices.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Apr 2017 14:20:58 +0200

>that people can make it look like IPv4 to suit their current operational 

I find 'cripple' a very odd choice in this context.

In my experience, IPv4 networks that have plenty of public IPv4
addresses can work very well. There is absolutely no evidence that using the
same techniques for IPv6 would cripple IPv6.

RA/SLAAC/RDNSS offer some benefits that are hard to realize with DHCP.
However, looking at the history of RA/SLAAC/RDNSS we can also see an endless
number of RFCs that try to correct various mistakes that were made initially.

In some networks, RA/SLAAC/RDNSS works really well and can do things you
can't do with DHCP. In other networks, forcing people to deploy 
RA/SLAAC/RDNSS is hugely disruptive and brings no benefits because those
networks are designed for DHCP.

As far as I can tell, none of the two options is inherently better. Both 
have their own strengths and weaknesses.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 3 Apr 2017 15:04:58 +0200 (CEST)

> networks are designed for DHCP.

I imagine you mean SLAAC A=1 is disruptive, ie hosts choosing their own 
addresses?

Or in what is RA as opposed to default-gw-in-DHCPv6 differ for the 
network?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Apr 2017 01:57:39 +1200

> I imagine you mean SLAAC A=1 is disruptive, ie hosts choosing their own 

There are certainly a lot of networks that work that way. When they need
asset management and traceability, they use MAC addresses. (MAC address
randomization is a considerable threat to this operating model, unlike
SLAAC.)

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Apr 2017 00:27:23 +1000

On 3 April 2017 at 20:27, Mikael Abrahamsson <[email-masked]> wrote:
>> doesn't support default gateways. Very few enterprises have a business need
>> to deploy IPv6, because it isn't solving for them a problem that IPv4 isn't
>> already or can't be used to solve.
>
>
> don't have to change the way they run things. I don't know what they end up
> doing in the long run, but I've seen many times where people will take
> whatever IPv4 design they had and try to cram in IPv6 into it with as little
> change as possible. I also have stated that they won't deploy IPv6 until
> Android gains IA_NA capability. "my network my rules".
>
> IPv6 as well". "Do you have SAVI on your switches?" "no" "then your tracking
> is not guaranteed" "it's good enough for $RULEMAKER".
>
> I have spent considerable time with people trying to convince them there are
> other ways to do what they need to do. At least the initial reaction is
> always "NOOOOOOOO", I don't know what the end result is.
>

So I don't think these people would actually be addressing a real
business need that IPv6 can only solve, because they have the luxury
of choosing not to deploy it.

> that people can make it look like IPv4 to suit their current operational

Agree.

I think there are a generation of network engineers that have learned
IPv4, and have not had any experience with past other networking
protocols such as IPX, Appletalk, CLNS etc. They may believe that the
way IPv4 solves various networking problems are both the only and best
ways to solve them, having not been exposed to any other ways to solve
them. (Radia Perlman's "Interconnections, 2nd Ed" is a great book on
different layer 3 protocols and how they solved similar problems.)

Some will be willing to accept the new and different IPv6 ways. Others
won't, and they'll likely be more vocal about it than those that just
accept that something new might be different (I'm not being
pejorative, it's human nature, it is common for people to resist
change.)

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 03 Apr 2017 16:46:45 +0200

>Or in what is RA as opposed to default-gw-in-DHCPv6 differ for the 

One thing that DHCP is good at, is giving hosts unique configuration parameters.
For example, some people have argued for a DHCPv6 default router parameter
because they give some hosts on a LAN a different default router.

Whether or not that make sense is a different question. If your network is
designed like that, then having to redesign it to make it work with RAs is
disruptive.

(Because it is easy to do in DHCPv4, some hosts on my home network have a 
different set of DNS resolvers. If all I had was RDNSS then probably I could
not have experimental DNS resolvers for some hosts without significant hacks).

At the same time, there have been various additions to RAs and SLAAC to make it
possible to have per host configuration. So in many ways RA/SLAAC is
made to emulate DHCP, badly.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Apr 2017 20:54:26 -0700

> On Apr 3, 2017, at 5:20 AM, Philip Homburg <[email-masked]> wrote:
> 

And there are no such RFCs for DHCPv4? I think not… Especially if you consider that
it started from BOOTP.

Any new protocol is bound to have some corrective and at least a few expansive RFCs
to add features and/or correct errors.

> networks are designed for DHCP.

I think the term “hugely disruptive” is a bit of an overstatement.

First, nobody is forced to deploy SLAAC or RDNSS and nobody is proposing that they should.
What is being proposed is that the implementation of RDNSS in routers and hosts be mandatory
so that if an operator chooses, they are available options. This is different from deployment which
would happen as a result of the operator choice.

Second, being forced to deploy RA is not particularly disruptive at all. It comes built-in to almost
every platform out there and an M=1, O=1, A=0 RA takes very little configuration on the router
to achieve. (which is all you need to do DHCP)

> have their own strengths and weaknesses.

On this, I completely agree, hence my pushing for both to be MTI and let the operator decide
what fits the needs in his/her particular situation.

Owen