Subject: Re: [v6ops] New Version Notification for draft-yourtchenko-ra-dhcpv6-comparison-00.txt (fwd)

From: Matthew Petach <[email-masked]>
Date: Wed, 8 Jan 2014 18:56:02 -0800

On Tue, Jan 7, 2014 at 10:10 AM, Owen DeLong <[email-masked]> wrote:

>
>
>> As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only
>> and Both.
>>
>> The scenarios where RA-Only make sense are any scenario where you do not
>> need greater control of the client configuration than Prefix information,
>> routing information, and DNS resolver addresses and search strings.
>>
>> In any scenario where you need to supply the host with more configuration
>> information on a dynamic basis, DHCPv6 is also required.
>>
>> Also, if you want dynamic DNS updates, deterministic assigned suffixes,
>> etc., these fall into the DHCPv6 realm.
>>
>> It's really as simple as that as near as I can tell.
>>
>> If you want to run without RAs, then you are into the realm of static
>> configuration. I, personally, do not see this as a problem.
>>
>
> Or, you're a company with tens of thousands
> of desktops, where static configuration is not
> a viable option, but control over address
> assignment from central servers is a must;
> in that environment, DHCPv6-assignment-only is
> a reality, and will exist; it is already being explored
> today, and to to deny that it is coming is equally as
> useful as cursing the coming of nightfall; it
> will happen, with or without your agreement
> or support.
>
>
> We are talking about two different things…
>
> DHCPv6-assignment-only is possible today. It is what happens if you set
> the M bit in the RA. DHCPv6 will then have full control of address
> assignment.
>
> What is not possible today is to do that DHCPv6 assignment without
> receiving an RA to instruct the host to do so.
>
> Why is that a problem for the network environments you have described?
>

I'm sorry, it's been a really busy week, so I'm a bit behind in
following up to the people who have asked for further clarification.

Here's the slightly more detailed description of the situation:

4 groups of hosts on the subnet;
groupA, groupB, groupC, groupD;
four different policies on the DHCP server.
subnet has 4 different upstream routers.
groupA is handed IP address on routerA as default gateway
groupB is handed IP address on routerB as default gateway
groupC is handed IP address on routerC as default gateway
groupD is handed IP address on routerD as default gateway

all four groups are within the same L2 broadcast domain,
and have applications that make use of that same-subnet
relationship.

In looking at DHCPv6 vs RAs, I don't see how to give the
different groups of hosts the appropriate default router IP
unless the default router is provided by the DHCP server.
The routers don't have a way to target their respective
RAs to just members of the appropriate group of hosts,
and there doesn't seem to be an option to tell the hosts
in groupA to only listen to RAs from routerA.

> As to getting software to do it, that’s not really the problem. The
> problem is that there’s already lots of deployed hardware and software that
> is implemented as defined in the current RFCs.
>
> It’s the elimination of RAs that is problematic. Using DHCP exclusively
> for address assignment isn’t difficult. Adding routing information to
> DHCPv6 wouldn’t be all that difficult.
>
>
So, I apologize for the confusion.  I didn't mean that RAs need
to go away; I simply meant we need a way for the hosts to
ignore the default router information from the RA, and instead
to obtain that from DHCPv6.  Essentially, having the RA only
pass the "go ask DHCPv6" option bits to the hosts, and
everything else gets superseded by what the DHCPv6
server sends to the host.

> Eliminating RAs from the process would require a major change that would
> likely pose some level of compatibility problem with existing deployments.
>
> Owen
>
>
Sorry; it's not really eliminating the RAs from the process as much
as saying "ignore what the RA is sending you, other than the
option bits telling you to go ask the DHCPv6 server for your info,
and use what the DHCPv6 server gives you, including your
default route information."

I hope that's a bit clearer; sorry to not have been clearer
earlier.

Thanks!!

Matt

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Jan 2014 19:17:08 -0800

On Jan 8, 2014, at 18:56 , Matthew Petach <[email-masked]> wrote:

>> As such, the options are not DHCPv6 only, RA-only, and Both, but, RA-only and Both.
>> 
>> The scenarios where RA-Only make sense are any scenario where you do not need greater control of the client configuration than Prefix information, routing information, and DNS resolver addresses and search strings.
>> 
>> In any scenario where you need to supply the host with more configuration information on a dynamic basis, DHCPv6 is also required.
>> 
>> Also, if you want dynamic DNS updates, deterministic assigned suffixes, etc., these fall into the DHCPv6 realm.
>> 
>> If you want to run without RAs, then you are into the realm of static configuration. I, personally, do not see this as a problem.
>> 
> DHCPv6-assignment-only is possible today. It is what happens if you set the M bit in the RA. DHCPv6 will then have full control of address assignment.
> 
> What is not possible today is to do that DHCPv6 assignment without receiving an RA to instruct the host to do so.
> 

Ignoring for the moment that this is an incredibly convoluted corner case which is likely fragile, at best, in IPv4...

In IPv4, that makes sense. In IPv6, it does not.

In IPv6, you don't have broadcasts, it's all multicast. You can define a multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6 subnets.

> unless the default router is provided by the DHCP server.

That's because you haven't looked at the fact that in IPv6, these don't need a shared broadcast domain to continue working the way you describe.

> in groupA to only listen to RAs from routerA.

You could, but it would involve elaborate configuration on the routers. It makes more sense to divide these groups of hosts into separate IPv6 networks.

> 
> As to getting software to do it, that’s not really the problem. The problem is that there’s already lots of deployed hardware and software that is implemented as defined in the current RFCs.
> 
> It’s the elimination of RAs that is problematic. Using DHCP exclusively for address assignment isn’t difficult. Adding routing information to DHCPv6 wouldn’t be all that difficult.
> 
> 

I don't see a mechanism for not treating a router announcing RAs as a candidate default route is likely to succeed. I think it would require modifications to host stacks that could not be backward compatible with existing implementations.

I'm all for adding RIO equivalence in DHCPv6, though I think it is significantly less useful than advocated.

> 
>  
> Eliminating RAs from the process would require a major change that would likely pose some level of compatibility problem with existing deployments.
> 
> Owen
> 
> 

I can certainly see ways to suggest that DHCPv6 route information, if presented, should supersede any route information learned via RA. I don't see ignoring the RA information completely.

> I hope that's a bit clearer; sorry to not have been clearer

Much clearer. I have to ask... Do you have a running network where this actually is still in use? I've seen a few environments like this, but most of them were deprecated years ago due to various problems that they create in IPv4.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jan 2014 14:29:18 +1100

In message <CAEmG1=rRYwJaZp3qYF47=[email-masked]>
, Matthew Petach writes:
> >> The scenarios where RA-Only make sense are any scenario where you do
> >> not need greater control of the client configuration than Prefix
> >> information, routing information, and DNS resolver addresses and
> >> search strings.
> >>
> >> In any scenario where you need to supply the host with more
> >> configuration information on a dynamic basis, DHCPv6 is also required.
> >>
> > We are talking about two different things...
>
> >
> > As to getting software to do it, that's not really the problem. The
> > problem is that there's already lots of deployed hardware and software
> > that is implemented as defined in the current RFCs.
> >
> > It's the elimination of RAs that is problematic. Using DHCP exclusively
> > for address assignment isn't difficult. Adding routing information to
> > DHCPv6 wouldn't be all that difficult.
> >
> >

If you want all the nodes to not use the RA to set a default route
then set Router Lifetime to zero.

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     field can contain values up to 65535 and receivers
                     should handle any value, while the sending rules in
                     Section 6 limit the lifetime to 9000 seconds.  A
                     Lifetime of 0 indicates that the router is not a
                     default router and SHOULD NOT appear on the default
                     router list.  The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options.  Options that need time
                     limits for their information include their own
                     lifetime fields.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matthew Petach <[email-masked]>
Date: Wed, 8 Jan 2014 19:34:48 -0800

On Wed, Jan 8, 2014 at 7:17 PM, Owen DeLong <[email-masked]> wrote:

> Ignoring for the moment that this is an incredibly convoluted corner case
> which is likely fragile, at best, in IPv4...
>
>
It's actually not that convoluted; it allows you to segment
your traffic flows across different upstream devices/interfaces
without having to forklift upgrade your network infrastructure
completely.  defaultA is actually an HSRP address that is
master on routerA, backup on routerB; defaultB is master
on routerB, backup on routerC; defaultC is master on
routerC, backup on routerD; and defaultD is master
on routerD, backup on routerA.  Each router takes
care of 25% of the host load for the network that way.

> In IPv6, you don't have broadcasts, it's all multicast. You can define a
> multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6
> subnets.
>

But it requires your router be configured to route
multicast traffic between subnets in order for that
to work, when in the v4 space, the traffic between
hosts doesn't require participation from the router
for host-to-host communication to function.

> That's because you haven't looked at the fact that in IPv6, these don't
> need a shared broadcast domain to continue working the way you describe.
>

It's somewhat awkward telling a group of users
"so, in v4, you're on the same subnet and can
communicate directly; but in v6, you're on
different subnets and can't communicate
directly".  Yes, I suppose we could try to do
do non-homologous topologies for v4 and
v6 for dual-stacked hosts, but troubleshooting
that kinda scares me a bit.  :(

> You could, but it would involve elaborate configuration on the routers. It
> makes more sense to divide these groups of hosts into separate IPv6
> networks.
>

Would that mean having to go back and break
up the v4 topology to match what's best for v6,
or run a different topology for v6 and v4 on the
same hosts?

It kinda sounds like the message is "v6 is a
different beast, and to use it, you have to
redo your network, including your v4 topology,
to best match what v6 wants."

> I don't see a mechanism for not treating a router announcing RAs as a
> candidate default route is likely to succeed. I think it would require
> modifications to host stacks that could not be backward compatible with
> existing implementations.
>
> I'm all for adding RIO equivalence in DHCPv6, though I think it is
> significantly less useful than advocated.
>
>
>
>
> I can certainly see ways to suggest that DHCPv6 route information, if
> presented, should supersede any route information learned via RA. I don't
> see ignoring the RA information completely.
>

Sure, supersede vs ignore is fine; main point being
the DHCPv6 server knows better what that group of
hosts should be using than the router does, so the
host should use what the DHCPv6 server sends it,
not the RA message from the router.

> Much clearer. I have to ask... Do you have a running network where this
> actually is still in use? I've seen a few environments like this, but most
> of them were deprecated years ago due to various problems that they create
> in IPv4.
>
> Owen
>
>
Virtualization is actually increasing the number of deployments
in that mode, rather than decreasing them.

Matt

---

From: Matthew Petach <[email-masked]>
Date: Wed, 8 Jan 2014 19:40:34 -0800

On Wed, Jan 8, 2014 at 7:29 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <CAEmG1=rRYwJaZp3qYF47=
> [email-masked]>
> , Matthew Petach writes:
> >
>

OMG.  Yes!  That's perfect!  So, I need to change to
set the M and O bits, set lifetime to 0, and then
send the default route info via DHCPv6 and I should
be golden!  You're a lifesaver, thank you!

Matt

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Jan 2014 19:58:05 -0800

> care of 25% of the host load for the network that way.

Meh... There are better ways to achieve that, and, in that case, you don't care so much that group A goes to router A, you care that the traffic is semi-evenly divided between the routers. Having multiple RAs with equal preference will come reasonably close to that automatically.

> for host-to-host communication to function.

So?

> that kinda scares me a bit.  :(

It's not all that frightening, and, I agree that the cleaner solution is to just deploy RAs and not worry about it.

However, you stated that you specifically wanted group A using router A rather than just dividing up the traffic.

> or run a different topology for v6 and v4 on the

I think you'd have to break up the L2 broadcast domain to make it work correctly with RAs, but you might be able to get creative with switch filters on which RAs are allowed to reach which hosts and leave them in a single L2 broadcast domain. In the latter case, you could also use an FF02:: multicast and reach all the hosts without crossing a router. Seems like a huge pain to maintain, however.

> to best match what v6 wants."

More like "IPv6 is a different beast and if you've done truly strange things to work around deficiencies in IPv4, then the clean solutions available in IPv6 may be incompatible."

Seems to me that for the purpose you have described, advertising RAs from all 4 routers and letting the hosts each pick one would do the trick in IPv6 without modifying your IPv4 topology. If you have other reasons that you really want group A going out through router A, however, then things get trickier and you've got that pesky "IPv4 hack incompatible with IPv6 solution" problem.

> I don't see a mechanism for not treating a router announcing RAs as a candidate default route is likely to succeed. I think it would require modifications to host stacks that could not be backward…

Actually, I forgot about router lifetime=0... As Mark suggested, that works now and is a readily available hack if you want to disable learning IPv6 default routes by RA.

> not the RA message from the router.

For some definitions of "knows" and some contexts of "better".

> in that mode, rather than decreasing them.

Seems to me that there are much better ways to do what you describe for virtualization, but that's getting into a bit of a digression from the WG charter. Hopefully the information I have provided above can prove useful in addressing your issues without requiring major protocol surgery.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Jan 2014 15:07:38 +1100

In message <[email-masked]>, Owen DeLong write
s:
> >> information, routing information, and DNS resolver addresses and search
> >> strings.
> >>
> >> Also, if you want dynamic DNS updates, deterministic assigned
> >> suffixes, etc., these fall into the DHCPv6 realm.
> >>

So what?

> In IPv4, that makes sense. In IPv6, it does not.

In your opinion.

> multicast scope (ff04 perhaps?) that incorporates those 4 distinct IPv6

And how do the nodes know to listen to that address?

Just turn off default router assignment at the RA level and do it
via DHCPv6 for per host route assignment.

> You could, but it would involve elaborate configuration on the routers.
> It makes more sense to divide these groups of hosts into separate IPv6
> networks.

Yes, but that makes lots of other assumptions of capabilities of the
existing components of the network at both layer 1 and layer 2.

One should be able to upgrade just that nodes and the routers without
touching cabling, switches and hubs and get similar functionality
in both IPv4 and IPv6.  RA's as the only source of default routes
are not able to meet this requirement.

> existing implementations.

The existing host stacks should already be capable of using router
lifetime for this.

> > Eliminating RAs from the process would require a major change that
> > would likely pose some level of compatibility problem with existing
> > deployments.
> >
> > Owen
> >
> >
> actually is still in use? I've seen a few environments like this, but
> most of them were deprecated years ago due to various problems that they
> create in IPv4.
>
> Owen

---

From: [email-masked]
Date: Thu, 09 Jan 2014 06:35:24 +0100 (CET)

> be golden!  You're a lifesaver, thank you!

... except that you can't send the default route info via DHCPv6
today.

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 15:50:43 +0900

> and have applications that make use of that same-subnet

Ok, I see two ways to do this:

One way is to have the hosts simply ECMP over the 4 routers. That way you
get better load-sharing, too.

The other is to use unicast RAs. I think you could do it like this:

1. When the 4 first-hop routers receive an RA, they each make a RADIUS
request.
2. The RADIUS server would return a Route-IPv6-Information attribute
containing a default route with an infinite lifetime.
3. The designated router sends an unicast RA to the specified client, the
other three do nothing.
4. When renewal time comes up, have the host send an RS again and repeat.

Before you say "that's insane", consider the fact that it's almost exactly
the same flow as a relayed DHCPv6 request, and that it involves a similar
number of packets and the same amount of state.

You do have to keep MAC-to-default-gateway mappings in the RADIUS server,
but if you're doing this I suspect you already have MAC-to-IP mappings and
IP-to-default-gateway mappings in the DHCPv4 server.

I doubt there's any hardware that does this today, but you jumped into this
discussion by saying that there are multibillion-dollar enterprises that
are willing to pay vendors to implement the features they need. Why not pay
them to implement this? Yes, it's not DHCP, but on the plus side, it's all
IETF standard technology, and it should do what you want.

BTW - if this is a datacenter architecture built for load-sharing, I have a
feeling you might evolve away from it in the future (either to ECMP or to
something else) so you can get better load-sharing - even with four
routers, you're leaving bandwidth on the table.

Cheers,
Lorenzo

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Jan 2014 11:03:23 +0100

Matthew,

thanks for presenting a concrete use case.

> care of 25% of the host load for the network that way.

can I paraphrase the problem?
"the problem is how to get hosts to load balance across multiple first-hop routers?"

or did I miss something?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 19:09:49 +0900

> "the problem is how to get hosts to load balance across multiple first-hop

That's an easy problem to solve - do ECMP on the hosts.

Unfortunately, though, I fear that the problem is "we want the IPv6 design
to be the same as the IPv4 design we already have", and in general that's a
problem that's impossible to solve without making IPv6 look the same as
IPv4.

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Jan 2014 11:26:37 +0100

> That's an easy problem to solve - do ECMP on the hosts.

right.

> Unfortunately, though, I fear that the problem is "we want the IPv6 design to be the same as the IPv4 design we already have", and in general that's a problem that's impossible to solve without making IPv6 look the same as IPv4.

that's not a class of problem I think we're able to solve in the IETF.

I think it is a perfectly valid operational model to manually / statically configure hosts though. Router Discovery provides a dynamic way to discover a router for default, that handles multiple routers, adjusts dynamically as the network changes.
manual configuration doesn't do any of that, but that doesn't mean there isn't a place for manual configuration.
if operators want to configure the default route with something like Puppet or Netconf isn't that acceptable with you?
DHCP would just be another way to do manual configuration of static information to hosts.

if this was implemented in DHCP, and the expectation was that all hosts should support it,
how does the deployment model and transition phases look like?
e.g. you have a mixed link with some hosts supporting the option and some hosts that don't.
is static DHCP configuration mutually exclusive with router discovery?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2014 06:56:42 -0500

> and have applications that make use of that same-subnet

So is the problem you are trying to solve here essentially a cheap SDN solution?   Why not simply isolate the four groups of hosts onto four separate VLANs?

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 11 Jan 2014 18:56:39 +0000

Lorenzo,

In IPv4, Matt's approach will work out of the box on any router with any
dhcp implementation, no fancy configuration required.

Matt needs to run DHCPv6 anyway, but your proposal requires him to tie
RADIUS into RAs via the next-hop router for gateway selection.  Apart from
the fact that this is three protocols instead of one, two of which are
policy management protocols (direction violation of KISS principal), it
requires the routers to maintain a pile of RADIUS state which they don't
need to do, opens them up to DoS attacks (requests from multiple v6
addresses), looks unnecessarily fragile and looks like the sort of proposal
that no vendor in their right mind would ever implement.

Whether you want to refer to this as "insane" is of course your own choice,
but I am glad that you have at least some appreciation that this suggestion
hails from the Heath Robinson school of network design.

Nick

On 09/01/2014 06:50, Lorenzo Colitti wrote:
> 1. When the 4 first-hop routers receive an RA, they each make a RADIUS request.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 12 Jan 2014 10:07:28 +0900

On Sun, Jan 12, 2014 at 3:56 AM, Nick Hilliard <[email-masked]> wrote:

> Matt needs to run DHCPv6 anyway,

Because... ? If Matt works for the same billion-dollar enterprise he worked
for a while ago, then he runs a single-tenant datacenter, where it's
perfectly reasonable to configure the hosts via other protocols than DHCPv6.

> it requires the routers to maintain a pile of RADIUS state

Nope: RS in, RADIUS request out, RADIUS reply in, RA out. No state.

> which they don't need to do, opens them up to DoS attacks (requests from
> multiple v6 addresses),

Which they have to in DHCPv6, too - anyone on the link can send them a
request.

> Whether you want to refer to this as "insane" is of course your own
> choice, but I am glad that you have at least some appreciation that this
> suggestion hails from the Heath Robinson school of network design.
>

I don't know how you can say that, given that the number of packets is the
same:

In DHCPv6, a multicast solicit request gets sent. The router receives it
and sends a request to a server, the server sends an answer back to the
router, and the router relays it to the host.

In this scheme, a multicast RS gets sent. The router receives it and sends
a RADIUS request to the server, the server sends an answer back to the
router, and the router sends an RA to the host.

Regardless of that - it seems to me that in a single-tenant architecture,
ECMP over multiple RAs is a much better solution, and the only reason that
Matt has this design in the first place is that *you can't do that in
DHCPv4*.

---

From: Matthew Petach <[email-masked]>
Date: Sun, 12 Jan 2014 23:27:22 -0800

On Thu, Jan 9, 2014 at 3:56 AM, Ted Lemon <[email-masked]> wrote:

> So is the problem you are trying to solve here essentially a cheap SDN
> solution?   Why not simply isolate the four groups of hosts onto four
> separate VLANs?
>
>
That would either require rewriting the applications running on the
hosts to use unicast communication between them, with a
corresponding increase in the volume of traffic, or implement
some scheme for handling non-unicast frames between
VLANs that I'm not currently aware of.

I realize this setup isn't typical; but it's there, and I find it
odd that the reaction from the community seems to be
"people should stop trying to stretch the lifespan of
IPv4 and just move to IPv6" at the same time saying
"you should stop doing things the v4 way, and change
your mindset and topology to match the v6 way".

The more impediments and roadblocks there
are to seamlessly converting from v4 to v6 there
are, the less incentive there is to move away from
v4, and the longer it is we'll continue to have v4-only
sites on the internet...which will continue to ensure
that the v6-only internet can never become reality.

As long as we're OK with v6 being a cute side project,
and not a fully functional replacement for v4, that's
a fine mindset to have.  But if we're serious about
wanting to move the Internet wholesale to v6, we
need to ease up a bit on this whole "If you won't
convert to the One True V6 Way, you should just
stay on v4" mantra.  I get that what we're doing in
the v4 world can't currently be done in the v6 world.
What I don't understand is why there's so much
resistance to making it possible to do it in the v6 world?

Matt

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 Jan 2014 09:42:41 +0100

> your mindset and topology to match the v6 way".

the problem you are trying to solve is load-balancing among multiple first-hop routers on the link, right?
RFC4311 doesn't do what you want?
(assuming it was implemented).

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2014 08:04:21 -0500

> On Jan 13, 2014, at 2:27 AM, Matthew Petach <[email-masked]> wrote:

I didn't say any of the things you said someone had said to you after this paragraph, so I won't respond to that, but could you please explain the application that drives you to use this configuration?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Jan 2014 02:48:09 +0900

> resistance to making it possible to do it in the v6 world?

Because making IPv6 look like IPv4 in every way will inevitably mean that
we'll lose the advantages that IPv6 has over IPv4. I'm not talking about
"QoS" or "security", which were trumpeted as advantages of IPv6 ten years
ago. I'm talking about the real advantages, like network statelessness, the
freedom from on-link address scarcity, dynamic renumbering, etc.

At the end of the day, it's a trade-off. Do you make IPv6 look more like
IPv4, in the hope that it will get deployed more quickly? Or do we stick to
the design and accept some temporary migration pain for a better end
result? I'm for the latter, because this thing's going to be with us for
thirty years - and because making it IPv6 more like IPv4 will *not* get
IPv6 deployed faster, because that's a business decision, not a technical
decision.

Many have said, "Where's the harm? So let's define standards to put routing
in DHCP. There's no harm in making the semantics compatible with IPv4, as
long as we maintain the routing in RA compatibility as well". I think these
people are either underestimating the network effect or the realities of
operations, "modern corporate IT staffing" (as Owen puts it), and the code
and process bugs that invariably crop up when you try to do something a
little different. Using the IPv4-lookalike way will always be the path of
least resistance, and at the end, there will only be one way to do
communicate configuration parameters to general-purpose hosts. Everything
else is simply too operationally expensive.

In your specific case, I'd argue that - as Ole has said - what you want to
do should be 100% solved - and with better load-sharing properties than
your current IPv4 design - by simply having the hosts ECMP to the four
routers. If your hosts don't support that, then I would see that as an
excellent use of your "as a multibillion dollar company, we can afford to
pay for the features we need" cachet.

Regards,
Lorenzo

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 Jan 2014 18:58:15 +0000

> freedom from on-link address scarcity, dynamic renumbering, etc.

network statelessness may be good on your network, but it's not a good
thing on my networks; apparently not Matt's either.  Nor is it good for the
people who've been pushing for and who now use stateful address
configuration on their v6 networks.

2^64 on-link addresses per configured subnet opens up a crippling DoS
vector with neighbor cache exhaustion, and should be considered an danger
to functional network operation in many production situations.

dynamic renumbering is a fantasy in many configuration scenarios.

> At the end of the day, it's a trade-off. Do you make IPv6 look more
> like IPv4, in the hope that it will get deployed more quickly? Or do we
> stick to the design and accept some temporary migration pain for a
> better end result? I'm for the latter, because this thing's going to be
> with us for thirty years - and because making it IPv6 more like IPv4
> will *not* get IPv6 deployed faster, because that's a business decision,
> not a technical decision.

You've inadvertently put your finger on exactly the problem.

Each network is different and requires different configuration to operate
optimally.  Your and other peoples' continuing efforts to block
standardisation of a DHCPv6 routing option using any means possible -
endless arguments and continuously shouting everyone down - do nothing to
hide the reality that your viewpoint of how ipv6 ought to operate is not
the only valid viewpoint out there.

Going back to what you said above, a "better end result" for your network
is not necessarily the same as for my network.

I do not want to stop you from using RAs and SLAAC if that's what works
well for you.  You are the best judge to know what's good for your networks
and I respect that.

Conversely, I ask you to accept that there are many people - including me -
who hold a considered viewpoint that routing information auto-
configuration using DHCPv6 would be a good fit for our requirements and
that you are not the best judge of what is or is not appropriate for our
networks.

Nick

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jan 2014 11:24:40 -0800

On Wed, Jan 22, 2014 at 10:58 AM, Nick Hilliard <[email-masked]> wrote:

> Your and other peoples' continuing efforts to block standardisation of a
> DHCPv6 routing option using any means possible - endless arguments and
> continuously shouting everyone down - do nothing to hide the reality that
> your viewpoint of how ipv6 ought to operate is not the only valid
> viewpoint out there.
>

I don't think that's a useful line of reasoning. You argue that I and
people like me cause endless arguments, but I could just as well argue that
you and people like you are causing the endless arguments are the people
who are constantly calling for the specifications to change to support
their views.

> that you are not the best judge of what is or is not appropriate for our

We've been through this before. I do accept that it's better in your
network (though perhaps not in Matt's; ECMP does seem a better solution). I
just don't agree that standardizing routing in DHCP to make your network
work better is the right tradeoff for the Internet as a whole. The way I
see it, changing the standards has knock-on effects on host implementations
and other networks, and I believe that if you look at the system as a
whole, it will be a net loss.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 Jan 2014 23:06:08 +0000

> who are constantly calling for the specifications to change to support

That's how the IETF works: people perceive a need and make a proposal and
have been doing so for a dhcpv6 defgw/routing option for several years.
The reason it comes up regular as rain is that many people think it's a
sensible thing to do.

The difference in this situation is that one way or another, what I and
others are suggesting will make exactly no difference whatsoever to how you
want to run your networks, because you can continue to run your networks
with RAs and SLAAC unimpeded and will be able to continue to do so in future.

On the other hand, your position is that we should not have this
standardised component to configure our networks in the way we see fit: not
now, not ever.  It is incredibly frustrating to be at the receiving end of
this position.

> whole, it will be a net loss.

The proposal in itself does not have knock-on implications.  It's just a
dhcp option like ntp- or dns-server, end of story.

Defining a set of semantics so that it can interoperate sensibly with RAs
will take a modest amount of work.  draft-ietf-v6ops-dhcpv6-slaac-problem
will be an important part of this.  What's important is that it's
completely doable.

Nick