Subject: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Mar 2013 17:09:31 +0100

Dear participants to V6OPS,

Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute
configuration to Client?

As one may remember, there was much discussion in several groups about
DHCPv6 delivering routing information to Clients: generic routes,
default routers' addresses and routes keyed by source address.

The MIF WG has produced a document
draft-ietf-mif-dhcpv6-route-option-05
but it is recently dropped from the MIF Charter to allow group to
re-focus on a MIF topic.

An individual proposal about DHCPv6 Default Routers List that I
co-author is in
draft-mouton-mif-dhcpv6-drlo-02.txt
which takes on an earlier  draft-droms-dhc-dhcpv6-default-router

In the DHCWG there was recently discussion about IEEE 802.11ai needing
to configure DefaultRouters by using link-layer messaging, or
alternatively DHCP.  With a purpose to realize fast configuration in
crowded hotspot areas for highly mobile STAs.

Also in DHCWG there was discussion about the src-based routes being
communicated to Client with DHCPv6.

Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute
configuration to Client?

Alex

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Mar 2013 15:16:54 +0900

> Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute

it would make it easier for current enterprise operators to add ipv6
to their network.  this has long been considered unacceptable by the
ipv6 gods.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Mar 2013 15:46:29 +0900

Alexandru,

v6ops does not create protocols. You should probably take this to 6man.

Regards,
Lorenzo

On Wed, Mar 27, 2013 at 1:09 AM, Alexandru Petrescu <
[email-masked]> wrote:

> draft-ietf-mif-dhcpv6-route-**option-05
> draft-mouton-mif-dhcpv6-drlo-**02.txt
> which takes on an earlier  draft-droms-dhc-dhcpv6-**default-router
>
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 08:54:35 +0100

> Is there an interest in DHCPv6 Route/DefRouter/Src-basedRoute

The big issue with having DHCPv6 deliver a default route is that it breaks the fate sharing that having the default router address in a router advertisement from the router holding that address provides.

But I gather there are people who want to be able to make one group of hosts on a subnet use router A as their default router but another group of hosts router B, on that same subnet.

My suggestion: rather than having a DHCPv6 option that flat out specifies a default router address, make an option that tells the host which router address it should pick when multiple are available. If everything is configured correctly this leads to the exact same result, but it degrades much more gracefully when there are problems.

Also, don't forget that the DHCPv6 implementation is not a user-serviceable part in the most widely used operating systems, and as such it will take a long time to get anything new implemented (publication of RFC 3315 -> implementation in MacOS: 8 years) so there will be a long time during which hosts not supporting the new option and hosts supporting the new option will have to coexist.

One might also observe that routing protocols exist and their convergence properties are a better fit to the task of delivering routing information than that of DHCP.

---

From: Doug Barton <[email-masked]>
Date: Wed, 27 Mar 2013 01:13:49 -0700

> The big issue with having DHCPv6 deliver a default route is that it breaks the fate sharing that having the default router address in a router advertisement from the router holding that address pro…

And yet that's not a problem for the hundreds of millions of hosts in 
the world configured with DHCPv4.

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Mar 2013 08:41:45 +0000

> v6ops does not create protocols. You should probably take this to 6man.

I think he's asking whether there is an operational need for this.

If there's an operational need, the actual protocol development will
be done elsewhere. It might be reasonable to develop a requirements
document here.

I'm not an operator, but it seems to me that any site planning to use
DHCPv6 to manage its IPv6 setup, including multiple prefixes, would
be looking for something in this space.

> to their network.  this has long been considered unacceptable by the

The gods must be crazy.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Mar 2013 09:47:58 +0100

Doug Barton wrote:
>> The big issue with having DHCPv6 deliver a default route is that it
>> breaks the fate sharing that having the default router address in a
>> router advertisement from the router holding that address provides.
>
Exactly. We have NUD in IPv6.

The default router list populated by RA is "A list of routers to which
packets may be sent." Note the may.

Any end node that continues to send packets to a dead router when it has
feasible alternatives is brain dead.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 09:55:40 +0100

> And yet that's not a problem for the hundreds of millions of hosts in the world configured with DHCPv4.

Ah yes, but what about the hosts that fail to be configured with IPv4 DHCP? We all experience this from time to time, but few people realize that it's the DHCP that's the issue.

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Mar 2013 02:05:07 -0700 (PDT)

>________________________________
> From: Iljitsch van Beijnum <[email-masked]>
>To: Alexandru Petrescu <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Wednesday, 27 March 2013 6:54 PM
>Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?
> 

This should already possible using RAs, with an example implementation being the clients section in radvd/radvd.conf. Here is the manual page help text:

       By  default  radvd will send route advertisements so that every node on
       the link can use them.  The list of clients (IPv6 address) to advertise
       to,  and  accept  route solicitations from can be configured.  If done,
       radvd does not send send messages to the multicast addresses but to the
       configured  unicast addresses only.  Solicitations from other addresses
       are refused.  This is similar to UnicastOnly but includes periodic mes‐
       sages  and  incoming client access configuration.  See examples section
       for a use case of this.

       The definitions are of the form:

       clients {
               list of IPv6 addresses
       };

Further into the manual page is an example configuration:

       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
               };
               clients
               {
                       fe80::21f:16ff:fe06:3aab;
                       fe80::21d:72ff:fe96:aaff;
               };
       };

       This   configuration   would    only    announce    the    prefix    to
       fe80::21f:16ff:fe06:3aab  and  fe80::21d:72ff:fe96:aaff.   Furthermore,
       all RA requests of other clients are denied.

       This may come in handy if you want to  roll  out  IPv6  only  partially
       because some clients are broken or untested.

<snip>

Regards,

Mark.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 27 Mar 2013 09:08:48 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, March 27, 2013 4:42 PM
> To: [email-masked]

[Bing] Agreed. In multihoming case, if the ISPs enabled ingress filtering, then there comes an exit router selection problem, which seems requiring both the hosts and the routers to deploy source-based routing.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Mar 2013 18:11:08 +0900

On Wed, Mar 27, 2013 at 5:13 PM, Doug Barton <[email-masked]> wrote:

> The big issue with having DHCPv6 deliver a default route is that it breaks
>> the fate sharing that having the default router address in a router
>> advertisement from the router holding that address provides.
>>
>

But it is a problem for the network administrators, because they are forced
to run VRRP to overcome the lack of fate sharing.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Mar 2013 10:26:59 +0100

Lorenzo Colitti wrote:
> On Wed, Mar 27, 2013 at 5:13 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         The big issue with having DHCPv6 deliver a default route is
>         that it breaks the fate sharing that having the default router
>         address in a router advertisement from the router holding that
>         address provides.
>
>
> But it is a problem for the network administrators, because they are
> forced to run VRRP to overcome the lack of fate sharing.
MIF thinks multi-interface is a problem with the current RA mechanism,
so there should be interest.

Not sure I get your logic, Lorenzo.

If DHCPv6 was used to populate a default router list, how would there be
a problem with fate sharing?
(assuming more than one router in the default router list, more than one
router acting as a DHCPv6 relay, and end nodes performing NUD)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 10:34:47 +0100

> router acting as a DHCPv6 relay, and end nodes performing NUD)

The DHCPv6 server may supply an incorrect router address, for one of two reasons:

- misconfiguration
- the router holding that address is down

This problem doesn't occur with RAs because the router address in an RA is automatically set so it can't be misconfigured, and if a router is down it won't be sending RAs.

Please note that we've had this discussion for many years now, it would be more fruitful to explore alternate ways to get the desired behavior than expecting the same arguments to be more persuasive this time around.

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 Mar 2013 11:18:31 +0000

>> to their network.  this has long been considered unacceptable by the

All this has happened before. All this will happen again.

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Mar 2013 20:29:41 +0900

> All this has happened before. All this will happen again.

Yes, but not forever.

All we need to do is get to a point where there is enough  IPv6 deployment
for enterprise operators to decide that they are going to deploy IPv6 even
though - oh, the sheer horror! - there is no way to configure routing in
DHCPv6.

Once they get past that and deploy using RAs, they will find out that it's
really not a problem. Our company's enterprise operators know this already.
We just need to give the others time to find out.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 27 Mar 2013 14:05:34 +0000

Good point regarding sites planning to use DHCPv6 may need things like this.   It would be beneficial to all to get ahead of the curve and consider providing such controls BEFORE Enterprises and Operators try to deploy and then discover issues that slow the deployment.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, March 27, 2013 4:42 AM
To: [email-masked]
Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?

If there's an operational need, the actual protocol development will be done elsewhere. It might be reasonable to develop a requirements document here.

I'm not an operator, but it seems to me that any site planning to use
DHCPv6 to manage its IPv6 setup, including multiple prefixes, would be looking for something in this space.

The gods must be crazy.

    Brian

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 16:25:57 +0100

> Good point regarding sites planning to use DHCPv6 may need things like this.   It would be beneficial to all to get ahead of the curve and consider providing such controls BEFORE Enterprises and Op…

There were similar sentiments around IPv6 PI. Now with PI in place the IPv6 routing table is certainly a lot larger than before, but there was not an immediate uptick in IPv6 deployment.

If the IETF standardizes a new, highly sought after DHCPv6 option, then that still doesn't buy anyone anything, because it needs to be implemented in a whole bunch of operating systems first. That takes many years.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 16:36:35 +0100

Le 27/03/2013 16:25, Iljitsch van Beijnum a écrit :
>> Good point regarding sites planning to use DHCPv6 may need things
>> like this.   It would be beneficial to all to get ahead of the
>> curve and consider providing such controls BEFORE Enterprises and
>> Operators try to deploy and then discover issues that slow the
>> deployment.
>
> There were similar sentiments around IPv6 PI. Now with PI in place
> the IPv6 routing table is certainly a lot larger than before, but
> there was not an immediate uptick in IPv6 deployment.
>
> If the IETF standardizes a new, highly sought after DHCPv6 option,
> then that still doesn't buy anyone anything, because it needs to be
> implemented in a whole bunch of operating systems first. That takes
> many years.

Iljitsch,

Is this worry about Route, DefRouters, src-basedRoute?

I believe the worry may be different in each case.

E.g. whereas DefRouter could be configured equally well by DHCP as much
as by RA, the src-basedRoute option does not exist in RA either.

I am trying to understand.

Alex

  _______________________________________________ v6ops
> mailing list [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 08:37:24 -0700

On Mar 27, 2013, at 4:29 AM, Lorenzo Colitti <[email-masked]> wrote:

> All we need to do is get to a point where there is enough  IPv6 deployment for enterprise operators to decide that they are going to deploy IPv6 even though - oh, the sheer horror! - there is no way to configure routing in DHCPv6.
> 

What is more likely is that DHCP server authors will develop this functionality to meet demand and it will eventually be documented as running code in an RFC.

> Once they get past that and deploy using RAs, they will find out that it's really not a problem. Our company's enterprise operators know this already. We just need to give the others time to find out.

There are a multitude of reasons that having an ability to place routing information into DHCPv6 would be useful to some operators. There are risks associated with doing so. Operators are, IMHO, capable of evaluating the tradeoffs and choosing the solution that best meets their needs.

Note that for maximum functionality, it should _NOT_ be limited to a default router.

It should be a routing information option which can be used to configure zero or more routes on the client.

Frankly, this would provide the ability to address some of the problems presented by ULA.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 16:48:36 +0100

Le 27/03/2013 12:29, Lorenzo Colitti a écrit :
> On Wed, Mar 27, 2013 at 8:18 PM, Tim Chown <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>> it would make it easier for current enterprise operators to add
>>> ipv6 to their network.  this has long been considered
>>> unacceptable by the ipv6 gods.
>>
>> The gods must be crazy.
>
> All we need to do is get to a point where there is enough  IPv6
> deployment for enterprise operators to decide that they are going to
> deploy IPv6 even though - oh, the sheer horror! - there is no way to
> configure routing in DHCPv6.

(there is no way to configure routing in DHCPv4 either).

But that is a good point.

I think migrating a network from IPv4 to IPv6 involves making IPv6 look
as much as possible as IPv4.

> Once they get past that and deploy using RAs, they will find out
> that it's really not a problem. Our company's enterprise operators
> know this already. We just need to give the others time to find out.

Ok, deploying RAs needs an effort of understanding RA.  And some people
already figured it out, somehow.

But, how do your company's enterprise operators maintain the supposedly
numerous radvd.conf files on the routers?  Do they think there may be a
problem in that?  (like e.g. when some PC software misinterprets the M/O
flags, or when the frequency must be increased because of a growing
number of PCs).

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 16:51:26 +0100

Le 27/03/2013 12:18, Tim Chown a écrit :
>> If there's an operational need, the actual protocol development
>> will be done elsewhere. It might be reasonable to develop a
>> requirements document here.
>>
>> I'm not an operator, but it seems to me that any site planning to
>> use DHCPv6 to manage its IPv6 setup, including multiple prefixes,
>> would be looking for something in this space.
>>

Not sure what 'all' refers to, but there is some novelty now vs before.

There is an SDO who seem to require something around this space,
otherwise they do it their own way.  This is new now.

Additionaly: we talk src-basedRoute in addition to Route and DefRouters.

How do you see what has happened before with respect to SDO?  And with
respect to src-basedRoute?

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 17:10:12 +0100

Le 27/03/2013 10:34, Iljitsch van Beijnum a écrit :
>> If DHCPv6 was used to populate a default router list, how would
>> there be a problem with fate sharing? (assuming more than one
>> router in the default router list, more than one router acting as a
>> DHCPv6 relay, and end nodes performing NUD)
>
> - misconfiguration - the router holding that address is down
>
> This problem doesn't occur with RAs because the router address in an
>  RA is automatically set so it can't be misconfigured, and if a
> router is down it won't be sending RAs.

For DefRouter --

Yes - one makes an RA to be that of a defaultrouter by setting the
Lifetime to non-zero value.  That's all; indeed it doesnt put an address
inside, but one has to set that value of lifetime.

Yes - if the router is down then no RA.

But,

Sure the problem can happen with RAs - I did myself in error.  I have
two Access Routers with two different egress links, yet a single
Ethernet link on which a Client PC connects to.

The PC receives two different RAs, each telling it it is the default
router.  My error was that I set one day one radvd.conf and another day
the other radvd.conf.  In the meantime I forgot which is the right
DefaultRouter.

So there I sit with a PC switching back and forth between the ARs, at a
high frequency.

That's a problem - misconfiguration, misunderstanding of where that
default route should come from, etc.

The problem happens as much with RAs as with any other protocol.

For src-basedRoute -- the argumentation doesnt hold because RA doesnt
advertise src-basedRoute.  If RA did that, then the RA had to contain an
src-basedRoute which should be present in the RA - hence
misconfiguration risks.

For Routes -- RA with RFC4191 specific routes doesnt really exist, so
this misconfiguration problem doesnt really exist either.  If it
existed, the misconfiguration problem existed as well.

> Please note that we've had this discussion for many years now, it
> would be more fruitful to explore alternate ways to get the desired
> behavior than expecting the same arguments to be more persuasive this
> time around.

Well, we need a place to discuss this.  I currently try here.

There are new arguments now, like that SDO.

Alternate ways - I am open to suggestions of alternate ways for DHCPv6
DefRouters to small PC Mobile Router for fast configuration.  Listening.

IMHO, for these alternate ways - in my particular case of DefRouters
DHCPv6, using small PC Mobile Router which needs to use a single and
fast protocol to configure as many parameters as possible, one
alternative is the use of Neighbor Discovery Prefix Delegation.

That alternative has much less tract.  There is a single individual
draft now, and another one in 2007.  There is no SDO asking for this
ND-PD, no expired WG item, a few and negative comments of being
architecturally problematic.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 17:18:45 +0100

Le 27/03/2013 10:05, Mark Smith a écrit :
>> But I gather there are people who want to be able to make one group
>> of hosts on a subnet use router A as their default router but
>> another group of hosts router B, on that same subnet.
>>
>
> This should already possible using RAs, with an example
> implementation being the clients section in radvd/radvd.conf.

Thank you for the example below.  That helps to have two Access Routers 
to configure clients differently on the same link, differentiating by 
clients' link-local unicast addresses.

This could work ok!  Although I doubt one could maintain such list of 
link-local addresses in multiple distributed radvd.conf files without 
some automation.

I may ask you whether such a method exists for src-basedRoute and Route 
as well?  I.e. is it possible to use RA to configure different Client 
PCs on the link with different src-basedRoutes, and different Routes?

But, for the case of DefRouters - this would fit fine some needs of 
small PC Mobile Router needing fast auto-configuration if RA did also 
Prefix Delegation.  Currently RA doesnt do such.

Alex

> Here is
> the manual page help text:
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 09:16:57 -0700

> as much as possible as IPv4.

There are some ways in which this can be beneficial. There are a number
of ways in which this would be a very bad idea.

For example, adding NAT to IPv6 to make it look like IPv4 would be very
detrimental. It will, unfortunately probably happen to some extent (sadly,
it already has). However, there is still tremendous benefit to be had from
limiting that extent.

I believe that providing routing information in DHCPv6 would offer benefits
beyond what a default router would. It should come with some level of
warning-label, however, because as has been pointed out, it can lead
to tradeoffs. It would not look like DHCPv4, but it would provide more
functionality and wouldn't look all that different. Default is just one case
of routing information that would then be possible.

e.g.

…
	routing-option { 2001:db8:1234::/48, 2001:db8:1234:fe96::1, 1002 };
	routing-option { ::/0, 2001:db8:1234:fe96::ea99, 512 };
…

This would provide two routes. The first, a /48 more specific to the local
prefix via a router at 2001:db8:1234:fe96::1 and the other a default via
a different router at …::ea99.

The first route has a metric of 1002. The second a metric of 512.

> already figured it out, somehow.

Deploying RAs is pretty straight forward and you have to do that anyway
just to bootstrap DHCP in most cases.

> flags, or when the frequency must be increased because of a growing

? There's only one radvd.conf file on any given router and that's only if the
router is running linux. Configuring routers is necessary no matter what.
Maintaining the RA configuration as part of the router configuration is nothing
unusual.

Normal routers configure RAs just like any other part of configuring a router:

fe-0/0/0 {
    unit 0 {
        description LAN;
        family inet {
            mtu 1500;
            filter {
                output deny-bad-actors;
            }
            address 192.159.10.251/24 {
                vrrp-group 1 {
                    virtual-address 192.159.10.254;
                    priority 250;
                    advertise-interval 5;
                    preempt;
                    accept-data;
                }
            }
            inactive: address 192.124.40.1/30;
        }
        family inet6 {
            mtu 1500;
            address 2620:0:930::dead:beef/64;
            address 2620:0:930::/64 {
                eui-64;
                primary;
            }
            address 2001:470:1f00:3142::dead:beef/64;
            address 2620:0:930::200:30/64;
        }
    }
}

The  above interface configuration is running code from a Juniper
SRX-100 providing RAs for SLAAC on the interface in question.

In this case, use of the "eui-64" configuration parameter is sufficient
to trigger RAs. One can add additional RA configuration options
within that address clause if necessary to control the content and
other aspects of the RAs more specifically, if needed. It is usually
not needed.

The primary keyword causes the router to use this address to
initiate sessions. It is unrelated to RAs.

Owen

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Mar 2013 01:25:09 +0900

> though - oh, the sheer horror! - there is no way to configure routing in

you have not figured it out, have you?  my way or the highway has led to
the nat4444 highway.  hope you like living in hell.  i don't and i don't
thank you for it.

randy

---

From: joel jaeggli <[email-masked]>
Date: Wed, 27 Mar 2013 09:36:24 -0700

> the world configured with DHCPv4.
Which continue to dhcpv4 forever in the absence of a dhcp server just 
like they did in 1995. I'll be coupled to the fact that IPV4 doesn't 
care if there's a router or not long after I have nominally v6only 
subnets because ipv4 doesn't have this relationship.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 17:47:11 +0100

Le 27/03/2013 17:16, Owen DeLong a écrit :
>
> On Mar 27, 2013, at 8:48 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>> <mailto:[email-masked]>

Right, I agree.

> it already has). However, there is still tremendous benefit to be had from

Right.

> functionality and wouldn't look all that different.

Right, a warning label should be added.  And no, it wouldnt look like 
DHCPv4 because this latter doesnt do routing to Client.

> Default is just one case of routing information that would then be
> possible.

Yes and no.

Yes conceptually a default route is just a route with all-zeros prefix 
and reset prefix length.

But in more detail the default route is present in addition in other 
IPv6-exclusive places - like the DefaultRoutersList of ND, where normal 
routes are absent.  That list has some parameters which dont exist with, 
or have different lengths than, mundane routes (lifetime, etc.).

Also, in other more human terms - often the entire effort of DHCPv6 
Route/DefRouters/src-basedRoute gets killed entirely only because of 
this DefRouter aspect.

I mean - it _could_ be possible to have a spec that DHCPv6 
Routes-nonDefault should have some status, and maybe another place which 
says that DHCPv6 defRoutes has other status.

A DHCPv6-Route-butnotDefRoutes (i.e. say that the prefix and its length 
each must be non-zero) whould not compete to either RA DefRouters, hence 
no reason to kill it.

A 
DHCPv6-Route-butnotDefRoutes-to-configureRouters-but-nottoconfigureHosts 
would not compete to RFC4191 either.

Rather than having nothing.

> a different router at …::ea99.

The syntax looks reasonable, expressing the contents of a fictitious 
dhcpd.conf file doing what we'd like to achieve with Routes and DefRouters.

I wonder how src-basedRoutes would fit?

> just to bootstrap DHCP in most cases.

YEs, in most cases.  One may also consider cases where RA is completely 
absent, no ND implementation. (e.g. RPL and 6lowpan machines).

> Maintaining the RA configuration as part of the router configuration is
> nothing unusual.

Well, I meant to ask how to update large number of radvd.conf files on 
multiple such access routers?

I don't know how people update these radvd.conf files with an automated 
manner.

I am asking because DHCP is easier to manage in that sense.  The Access 
Routers are pre-configured with the stable address of the Server, and 
one describes the entire topology of the Access Routers only in a single 
configuration file - dhcpd.conf.

Alex

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 18:06:01 +0100

On 27 mrt 2013, at 17:10, Alexandru Petrescu <[email-masked]> wrote:

> Sure the problem can happen with RAs - I did myself in error.

Of course there are ways to make RAs work incorrectly, but there's the fate sharing advantage and we've had RAs for 18 years now so the likelihood of problems is much smaller than with something new that doesn't have fate sharing.

> So there I sit with a PC switching back and forth between the ARs, at a

This is strange. The situation where two routers send out RAs is prefectly normal, you would expect a host to choose one default router and stick to that until the RA lifetime expires or neighbor unreachability detection kicks in. But it seems like the OS on your PC simply switched with every new RA received or did some kind of load balancing.

> The problem happens as much with RAs as with any other protocol.

Not as much.

And if you make another protocol, then you have a problem if one of the two doesn't work (~ 2 times as likely as that one of one doesn't work) or when the two provide conflicting information.

> advertise src-basedRoute.

Right. My arguments don't apply to that.

> Well, we need a place to discuss this.  I currently try here.

I think this is as good a place as any, for the time being. So no problem with that.

> There are new arguments now, like that SDO.

What SDO?

> DefRouters to small PC Mobile Router for fast configuration.  Listening.

My suggestion is that a new DHCPv6 option carries a list of preferred default routers. Then, if multiple default routers are available from RAs, the information from the DHCPv6 option allows the host to select the right one.

So in the case where everything works as expected, this provides the same functionality as having a default route in DHCPv6 the same way as with IPv4 DHCP.

However, if the router that the DHCPv6 server points to is down, there will be no RA from that router, and the host will use a different router. This makes the mechanism much more robust against failures.

Iljitsch

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 10:05:28 -0700

> Yes conceptually a default route is just a route with all-zeros prefix and reset prefix length.
> 
> But in more detail the default route is present in addition in other IPv6-exclusive places - like the DefaultRoutersList of ND, where normal routes are absent.  That list has some parameters which dont exist with, or have different lengths than, mundane routes (lifetime, etc.).
> 

But it doesn't _HAVE_ to have them outside of the ones provided by RA.

For example, if I type:

route -f inet6 add -net ::/0 gw 2001:db8::1

I get a default route that has none of those extra attributes. They are optional.

Further, nothing prevents other more specific routes from having those attributes, either. Likely any route configured via DHPCv6 would, in fact, have those attributes.

> Also, in other more human terms - often the entire effort of DHCPv6 Route/DefRouters/src-basedRoute gets killed entirely only because of this DefRouter aspect.
> 

I disagree. This effort gets killed because certain religious zealots in the IETF believe that systems administrators should not be granted any control over how packets move and it should be the exclusive province of network administrators/engineers/architects.

> I mean - it _could_ be possible to have a spec that DHCPv6 Routes-nonDefault should have some status, and maybe another place which says that DHCPv6 defRoutes has other status.
> 

To what possible advantage?

If we provide a generic route option where default is just a particular prefix/length combination (and there is actually some valid argument for using 2000::/3 rather than ::/0 for default for now, especially in light of the various problems caused by ULA. Unfortunately, RA does not support this behavior, but I digress).

> A DHCPv6-Route-butnotDefRoutes (i.e. say that the prefix and its length each must be non-zero) whould not compete to either RA DefRouters, hence no reason to kill it.
> 

I think you are not paying attention to the argument being raised by the vocal few who insist on killing this. For the most part, they are people that have opposed DHCP since before it was even documented in IPv4.

> A DHCPv6-Route-butnotDefRoutes-to-configureRouters-but-nottoconfigureHosts would not compete to RFC4191 either.

I'm still not seeing an advantage to doing this. I don't think it will improve the politics of the situation. It certainly doesn't provide a better alternative to operators.

> Rather than having nothing.

Based on discussions I've had with a variety of people in a position to control actual code development, I don't think that "having nothing" situation will last all that long. Every effort is being made to solve this problem within the IETF. If that doesn't work, it will eventually get solved without the IETF.

> The syntax looks reasonable, expressing the contents of a fictitious dhcpd.conf file doing what we'd like to achieve with Routes and DefRouters.
> 

They would not. If  you want policy routing, create an option to support that. I, personally, have no interest in the development of such an option. I don't have any strong objection to it, either, but I believe that policy routing has its own unique pathologies and should be treated separately from generic destination-based routing.

> Well, I meant to ask how to update large number of radvd.conf files on multiple such access routers?
> 

This doesn't usually happen. That's probably one of the reasons that this option is usually discounted when it is raised.

> I don't know how people update these radvd.conf files with an automated manner.
> 

Mostly, they don't. If you want a customized router configuration, you manage your routers. If you're talking about customizing the router configuration on a bunch of CPE routers, the average residential ISP will tell you that it is a non-starter.

> I am asking because DHCP is easier to manage in that sense.  The Access Routers are pre-configured with the stable address of the Server, and one describes the entire topology of the Access Routers only in a single configuration file - dhcpd.conf.

There is no available mechanism for this today.

Owen

---

From: Doug Barton <[email-masked]>
Date: Wed, 27 Mar 2013 10:22:55 -0700

> If the IETF standardizes a new, highly sought after DHCPv6 option, then that still doesn't buy anyone anything, because it needs to be implemented in a whole bunch of operating systems first. That…

So just like every other IETF protocol, the effect of the change won't 
be instantaneous. That doesn't mean we shouldn't do the right thing now, 
so that at some point down the road it can be used.

If this particular change had been done 12 years ago like some of us 
were asking the problem would have been solved a long time ago.

Doug

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 18:37:17 +0100

> So just like every other IETF protocol, the effect of the change won't be instantaneous. That doesn't mean we shouldn't do the right thing now, so that at some point down the road it can be used.

In general that's true, but with configuration stuff it's more complicated. See the situation where some OSes (Windows as of Vista) had DHCPv6 support but others (MacOS 10.6) didn't. That was a very unpleasant situation, because either you had to forego using DHCPv6 altogether, or you had to make a configuration that would work for both types (and probably suboptimally for at least one).

If someone really has a special need in this area, it's probably a better idea to install a routing daemon on their hosts rather than expect ALL hosts connected to the internet to implement something new that comes with additional failure modes.

> If this particular change had been done 12 years ago like some of us were asking the problem would have been solved a long time ago.

Maybe after 5 or 10 years it would have been a good idea to start looking at different options that provide the same benefits but are less contentious. See my suggestion at the end of my previous message.

Iljitsch

---

From: Doug Barton <[email-masked]>
Date: Wed, 27 Mar 2013 10:53:07 -0700

On 03/27/2013 10:37 AM, Iljitsch van Beijnum wrote:
>>> If the IETF standardizes a new, highly sought after DHCPv6
>>> option, then that still doesn't buy anyone anything, because it
>>> needs to be implemented in a whole bunch of operating systems
>>> first. That takes many years.
>
>> So just like every other IETF protocol, the effect of the change
>> won't be instantaneous. That doesn't mean we shouldn't do the right
>> thing now, so that at some point down the road it can be used.
>
> In general that's true, but with configuration stuff it's more
> complicated. See the situation where some OSes (Windows as of Vista)
> had DHCPv6 support but others (MacOS 10.6) didn't. That was a very
> unpleasant situation, because either you had to forego using DHCPv6
> altogether, or you had to make a configuration that would work for
> both types (and probably suboptimally for at least one).

No one is saying that it isn't going to take time to sort out the 
clients once the default router option is available. But the logical 
conclusion from that premise is not, "Don't do it," the logical 
conclusion is, "Do it as soon as possible."

> If someone really has a special need in this area, it's probably a
> better idea to install a routing daemon on their hosts rather than
> expect ALL hosts connected to the internet to implement something new
> that comes with additional failure modes.

Completely unrealistic.

The realistic scenario is: Fix the protocol, wait 3 years for the 
clients to be updated, then deploy IPv6. See below on why that's a 
perfectly acceptable scenario.

>> If this particular change had been done 12 years ago like some of
>> us were asking the problem would have been solved a long time ago.
>
> Maybe after 5 or 10 years it would have been a good idea to start
> looking at different options that provide the same benefits but are
> less contentious. See my suggestion at the end of my previous
> message.

Or, maybe (as Randy's message so ably stated) it would have been nice if 
people like you would realize that "my way or the highway" has resulted 
in the vast majority of operators taking the highway.

We make happy noises about wanting input from the operator community. 
But when the message of, "We want full parity with DHCPv4 in DHCPv6" 
comes through loud, clear, and consistently for over a decade certain 
among us choose to stick their fingers in their ears and sing 
"la-la-la-la-la, I can't hear you." It's not Ok to continue playing that 
game.

Enterprises have well established policies and procedures about who 
manages what bits of data/configuration/network policy/etc. They want to 
be able to manage DHCPv6 in a way that fits with their existing 
structures, and won't deploy IPv6 at all if they can't. And what some 
people around here seem to be missing is that there is absolutely no 
motivation for them to do so. In fact, there is little to no incentive 
for them to deploy v6 inside an end-user network at all right now, and 
there isn't going to be any time in the next 5 years for sure, and 
likely for another decade if not longer.

So keep up your ivory tower "my way or the highway" stance if you want. 
You can be quite happy up there in your ivory tower while the rest of 
the world moves right on by you.

Doug

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 27 Mar 2013 11:01:01 -0700 (PDT)

Doug,

You go, girl!
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Doug Barton <[email-masked]>
To: [email-masked] 
Sent: Wednesday, March 27, 2013 10:53 AM
Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?
 
> both types (and probably suboptimally for at least one).

No one is saying that it isn't going to take time to sort out the clients once the default router option is available. But the logical conclusion from that premise is not, "Don't do it," the logical conclusion is, "Do it as soon as possible."

Completely unrealistic.

The realistic scenario is: Fix the protocol, wait 3 years for the clients to be updated, then deploy IPv6. See below on why that's a perfectly acceptable scenario.

> less contentious. See my suggestion at the end of my previous

Or, maybe (as Randy's message so ably stated) it would have been nice if people like you would realize that "my way or the highway" has resulted in the vast majority of operators taking the highway.

We make happy noises about wanting input from the operator community. But when the message of, "We want full parity with DHCPv4 in DHCPv6" comes through loud, clear, and consistently for over a decade certain among us choose to stick their fingers in their ears and sing "la-la-la-la-la, I can't hear you." It's not Ok to continue playing that game.

Enterprises have well established policies and procedures about who manages what bits of data/configuration/network policy/etc. They want to be able to manage DHCPv6 in a way that fits with their existing structures, and won't deploy IPv6 at all if they can't. And what some people around here seem to be missing is that there is absolutely no motivation for them to do so. In fact, there is little to no incentive for them to deploy v6 inside an end-user network at all right now, and there isn't going to be any time in the next 5 years for sure, and likely for another decade if not longer.

So keep up your ivory tower "my way or the highway" stance if you want. You can be quite happy up there in your ivory tower while the rest of the world moves right on by you.

Doug

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 27 Mar 2013 18:07:41 +0000

In the large enterprise and data center operator environments there is still a great deal of resistance to IPv6.  The more things like this we can do to remove potential excuses the better in my view.   Even if we may have to wait.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 27 Mar 2013 18:23:01 +0000

Doug,

You speak for many of us!   Thanks!   

I push very hard for IPv6 in my organizations but the push back is strong when existing capabilities are removed.    

I realize in many cases the push backs are little more than feeble excuses, but nonetheless, they provide a convenient barrier and make it that much more difficult for those of us trying to promote IPv6.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Barton
Sent: Wednesday, March 27, 2013 1:53 PM
To: [email-masked]
Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?

Completely unrealistic.

> less contentious. See my suggestion at the end of my previous message.

We make happy noises about wanting input from the operator community. 
But when the message of, "We want full parity with DHCPv4 in DHCPv6" 
comes through loud, clear, and consistently for over a decade certain among us choose to stick their fingers in their ears and sing "la-la-la-la-la, I can't hear you." It's not Ok to continue playing that game.

So keep up your ivory tower "my way or the highway" stance if you want. 
You can be quite happy up there in your ivory tower while the rest of the world moves right on by you.

Doug

---

From: Philipp Kern <[email-masked]>
Date: Wed, 27 Mar 2013 19:38:18 +0100

Brian,

> I think he's asking whether there is an operational need for this.

I think there is an operational need to communicate flexible (source prefix,
destination prefix, route target) tuples to clients, regardless if that
protocol is DHCPv6 or RA.

(This lack is currently biting us with high bandwidth applications, on IPv4
however.)

Kind regards
Philipp Kern

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Mar 2013 12:11:50 -0700 (PDT)

Since the following it seems to have been missed, and this discussion is just burning up more bandwidth and peoples' time (perhaps for the 50th time in the last decade?), I'm reposting it.

RAs can be selectively unicast to clients, and the radvd IPv6 RA implementation provides that option. The email below has the manual page text and an example.

It may not be the way that DHCPv4 solved this problem (which perhaps is a symptom of IPv4 not having autoconfiguration from the outset), but all that does is make it a different way of solving the problem. The DHCPv4 model is not the be all and end all solution to all network configuration problems.

Other than other router implementations not providing the option to do unicast RAs to select clients (not a problem the IETF can solve), the only gap I can see that DHCPv4 fills verses unicast RAs for influencing client's default router selection is the ability to have the mapping of client to router centralised on a DHCPv4 server and then having routers use that information via DHCPv4 forwarding. So what is necessary for IPv6 is a method to either distribute the list of clients to unicast RAs map to to the routers, or to have the router query a centralised server when it receives an RS. That is a better solution than duplicating functionality from RAs into DHCPv6, as it would only require changes to router implementations, rather than the deployed IPv6 implementations in hosts, and avoid the inevitable issues around what to do when conflicting default router information is received from an RA verses DHCPv6.

----- Forwarded Message -----
> From: Mark Smith <[email-masked]>
> To: Iljitsch van Beijnum <[email-masked]>; Alexandru Petrescu <[email-masked]>
> Sent: Wednesday, 27 March 2013 8:05 PM
>> But I gather there are people who want to be able to make one group of hosts 
> on a subnet use router A as their default router but another group of hosts 
> router B, on that same subnet.
>> 
> 
> This should already possible using RAs, with an example implementation being the 
> clients section in radvd/radvd.conf. Here is the manual page help text:
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Mar 2013 20:48:17 +0100

> No one is saying that it isn't going to take time to sort out the clients once the default router option is available. But the logical conclusion from that premise is not, "Don't do it," the logica…

I don't think anyone is arguing for "do it, but wait half a decade first".

:-)

> Completely unrealistic.

You think it's less realistic to install some software under your own control on devices under your own control than getting IETF rough consensus after you couldn't get it for (at least) four years, and then wait for third parties with no skin in the game to implement it in their software?

> Enterprises have well established policies and procedures about who manages what bits of data/configuration/network policy/etc. They want to be able to manage DHCPv6 in a way that fits with their existing structures, and won't deploy IPv6 at all if they can't.

I am extremely skeptical of that argument. It's used for other stuff that did see the light of day in the past. So show me the evidence that this is true in this instance, and not just a convenient excuse to delay IPv6 deployment that was never going to happen anyway.

> And what some people around here seem to be missing is that there is absolutely no motivation for them to do so. In fact, there is little to no incentive for them to deploy v6 inside an end-user network at all right now, and there isn't going to be any time in the next 5 years for sure, and likely for another decade if not longer.

IPv4 is a profoundly flawed protocol. But we've used it for 30 years now. We'll have to use IPv6 for longer than that in all likelihood. So it's important to refrain from importing those IPv4 flaws in IPv6 as much as we can.

For that reason, when a whole bunch of protocol designers tell you a specific way to implement a feature you like is a bad way to do it, it might be useful to listen to them, and perhaps explore different ways to get that same feature.

So far you haven't bothered to address my suggestion of replacing a proposed DHCPv6 default router option with a DHCPv6 option that lets a host select the desired default router from the ones available through RAs.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Mar 2013 19:57:45 +0000

Hi Mark,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Smith
> Sent: Wednesday, March 27, 2013 12:12 PM
> To: v6ops v6ops WG
> Subject: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6
> Route/DefRouter/Src-basedRoute configuration to Client?
> 
> Since the following it seems to have been missed, and this discussion is
> just burning up more bandwidth and peoples' time (perhaps for the 50th
> time in the last decade?), I'm reposting it.
> 
> RAs can be selectively unicast to clients, and the radvd IPv6 RA
> implementation provides that option. The email below has the manual page
> text and an example.

Although I cannot say if it was *the* reason, one of the reasons
for this option was to accommodate ISATAP. That said, RFC4861
does permit unicasting of RAs.

Thanks - Fred
[email-masked]

> It may not be the way that DHCPv4 solved this problem (which perhaps is a
> symptom of IPv4 not having autoconfiguration from the outset), but all
> that does is make it a different way of solving the problem. The DHCPv4
> model is not the be all and end all solution to all network configuration
> problems.
> 
> Other than other router implementations not providing the option to do
> unicast RAs to select clients (not a problem the IETF can solve), the only
> gap I can see that DHCPv4 fills verses unicast RAs for influencing
> client's default router selection is the ability to have the mapping of
> client to router centralised on a DHCPv4 server and then having routers
> use that information via DHCPv4 forwarding. So what is necessary for IPv6
> is a method to either distribute the list of clients to unicast RAs map to
> to the routers, or to have the router query a centralised server when it
> receives an RS. That is a better solution than duplicating functionality
> from RAs into DHCPv6, as it would only require changes to router
> implementations, rather than the deployed IPv6 implementations in hosts,
> and avoid the inevitable issues around what to do when conflicting default
> router information is received from an RA verses DHCPv6.
> 
> 
> 
> 
> 
> 
> breaks

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Mar 2013 06:34:04 +0900

> the nat4444 highway.  hope you like living in hell.  i don't and i don't

Well, but I don't really think that's true.

What I've seen, over and over again, is that
teams/companies/enterprises/... say "we can't deploy IPv6 because of X",
but then, when X arrives, the very same people move on to saying "we can't
deploy IPv6 because of Y", where Y != X. So X is not the real reason, it's
just a red herring. What they are actually saying is "we see no need to
deploy IPv6 at the moment".

The IETF cannot create a business need to deploy IPv6. Perhaps it can lower
the barriers to adoption, but I'm skeptical that lowering this particular
barrier would make much difference at all. On the other hand, defining a
mechanism for distributing routes whose semantics are much weaker than the
one we have will lower the robustness of IPv6 and increase operational
costs (for example, by forcing us to run VRRP forever because there is no
fate sharing).

---

From: Tom Perrine <[email-masked]>
Date: Wed, 27 Mar 2013 15:40:01 -0700

On 3/27/13 2:34 PM, Lorenzo Colitti wrote:
> On Wed, Mar 27, 2013 at 9:25 AM, Randy Bush <[email-masked] <mailto:[email-masked]>> wrote:
>
> What I've seen, over and over again, is that teams/companies/enterprises/... say "we can't deploy IPv6 because of X",
> but then, when X arrives, the very same people move on to saying "we can't deploy IPv6 because of Y", where Y != X. So X
> is not the real reason, it's just a red herring. What they are actually saying is "we see no need to deploy IPv6 at the
> moment".

SNIP

I'm seeing the possibility of no longer having to coordinate RFC 1918 space across business units and partners as a 
compelling factor for adoption of IPv6.

Consider a large multinational that has had mostly independent *internal* networks (in 1918 space) for the past 10-20 
years, as they merge those together.  Throw in ongoing mergers and acquisitions and you can get a 10.0.0.0/8 and NAT 
nightmare from all the cruft that can accumulate over that period of time. Because, of course, renumbering is expensive 
and contributes nothing to the bottom line.  And network teams have gotten pretty good at gluing nets together with 
NATs. Add transient business partners that also used 1918 for their internal nets, that you now need to see inside of, 
or they need to see inside yours.

It can get..... interesting.

I saw a business case from one of those multinationals in November. They cut the time to merge in a newly acquired 
company's network from 12-24 months to less than 3 months by agreeing to only connect over IPv6 and doing 6/4 
translation at the boundaries as needed.

I think they also rolled some of the IPv6 transition costs for both companies (and the 6/4 translation project) in as 
part of the M&A costs :-) so they got an infrastructure upgrade and a new capability that they can reuse, that IT didn't 
have to pay for.

Finally, a carrot?

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 16:10:47 -0700

> In general that's true, but with configuration stuff it's more complicated. See the situation where some OSes (Windows as of Vista) had DHCPv6 support but others (MacOS 10.6) didn't. That was a ver…

But it got resolved because Apple succumbed to the pressure to implement DHCPv6.

Frankly, Apple would have done that a lot earlier if it hadn't been for all the IETF BS from people trying to block DHCPv6 in the first place.

> If someone really has a special need in this area, it's probably a better idea to install a routing daemon on their hosts rather than expect ALL hosts connected to the internet to implement somethi…

Not so much, no. These aren't special needs. This is a relatively common set of circumstances in much of the currently deployed network in the real world.

> Maybe after 5 or 10 years it would have been a good idea to start looking at different options that provide the same benefits but are less contentious. See my suggestion at the end of my previous m…

Maybe it would be good to stop standing in the way of something that has shown strong demand for so many years instead of preserving the contentiousness.

Owen

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 27 Mar 2013 16:15:35 -0700 (PDT)

Very interesting!
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Tom Perrine <[email-masked]>
To: IETF v6ops list <[email-masked]> 
Sent: Wednesday, March 27, 2013 3:40 PM
Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?

SNIP

I'm seeing the possibility of no longer having to coordinate RFC 1918 space across business units and partners as a compelling factor for adoption of IPv6.

Consider a large multinational that has had mostly independent *internal* networks (in 1918 space) for the past 10-20 years, as they merge those together.  Throw in ongoing mergers and acquisitions and you can get a 10.0.0.0/8 and NAT nightmare from all the cruft that can accumulate over that period of time. Because, of course, renumbering is expensive and contributes nothing to the bottom line.  And network teams have gotten pretty good at gluing nets together with NATs. Add transient business partners that also used 1918 for their internal nets, that you now need to see inside of, or they need to see inside yours.

I saw a business case from one of those multinationals in November. They cut the time to merge in a newly acquired company's network from 12-24 months to less than 3 months by agreeing to only connect over IPv6 and doing 6/4 translation at the boundaries as needed.

I think they also rolled some of the IPv6 transition costs for both companies (and the 6/4 translation project) in as part of the M&A costs :-) so they got an infrastructure upgrade and a new capability that they can reuse, that IT didn't have to pay for.

Finally, a carrot?

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 16:22:38 -0700

> I don't think anyone is arguing for "do it, but wait half a decade first".

No, but your consistent FUD every time this comes up has managed to delay it 12 years and counting.

It's going to get done. The question is whether it gets done within the IETF or without.

> You think it's less realistic to install some software under your own control on devices under your own control than getting IETF rough consensus after you couldn't get it for (at least) four years…

There's a difference now. The operator community is starting to pay more attention. IETF consensus would be nice, but the feature will most likely get implemented with or without IETF consensus at this point. IETF certainly could accelerate the process and improve it by finding consensus on the best way to implement the feature and documenting that.

> I am extremely skeptical of that argument. It's used for other stuff that did see the light of day in the past. So show me the evidence that this is true in this instance, and not just a convenient…

What evidence would you like?

I know there are definitely organizations where the IT department will strongly oppose IPv6 until such time as they can gain proper administrative controls over the clients. To their perspective, this includes controlling the selection of gateways.

WIll implementing this option instantaneously increase IPv6 uptake? No, of course it won't.

Will failing to do so continue to delay IPv6 uptake? You bet it will.

If you don't think that the number of people saying so on this list is evidence of this fact, then I'm not sure what form of evidence you are looking for.

Your claims that IPv6 PI has not lead to greater IPv6 adoption by multi homed end-users is also specious. There are, in fact, many end-user organizations that have made use of the PI IPv6 policy.

> IPv4 is a profoundly flawed protocol. But we've used it for 30 years now. We'll have to use IPv6 for longer than that in all likelihood. So it's important to refrain from importing those IPv4 flaws…

Allowing operators to specify routing information in DHCP isn't importing a flaw. It's providing a feature. I understand that you don't like eliminating fate sharing. Many operators want very badly to eliminate fate sharing for a variety of reasons. You run your network your way and let them run their network(s) their way. Unlike NAT or NPT, adding this option to DHCPv6 would not be harmful to anyone who doesn't use it. As such, your arguments against it do not really hold water in my book.

> For that reason, when a whole bunch of protocol designers tell you a specific way to implement a feature you like is a bad way to do it, it might be useful to listen to them, and perhaps explore di…

When a whole bunch of operators tell you that they don't agree, it might be good for protocol designers to consider what harm is actually done by implementing what is requested. When they realize that it is harmless, perhaps it is better to just implement it and move on rather than have the good aspects of what you have designed be tossed aside because of the inability to compromise over the religion about one particular feature.

> So far you haven't bothered to address my suggestion of replacing a proposed DHCPv6 default router option with a DHCPv6 option that lets a host select the desired default router from the ones avail…

1. It doesn't address the entire problem set.
2. You've now added a level of complexity (how is the DHCP server supposed to know what the available choices are?)
3. It offers no advantages over just providing a static routing option.
4. It addresses only the default router case and not the more general routing information case.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 16:25:49 -0700

On Mar 27, 2013, at 2:34 PM, Lorenzo Colitti <[email-masked]> wrote:

> What I've seen, over and over again, is that teams/companies/enterprises/... say "we can't deploy IPv6 because of X", but then, when X arrives, the very same people move on to saying "we can't deploy IPv6 because of Y", where Y != X. So X is not the real reason, it's just a red herring. What they are actually saying is "we see no need to deploy IPv6 at the moment".
> 

Lorenzo, this simply isn't always true.

It may be that they can't deploy IPv6 because of A, B, C, D, E, F, G, H, X, Y, and Z.

It may be that they tell you about X. When you eliminate X, they tell you about Y.

Eventually, they run out of reasons.

Just because they don't tell you all of the reasons at once does not mean that there are not multiple reasons.

There are red herrings out there, but this really isn't one of them.

> The IETF cannot create a business need to deploy IPv6. Perhaps it can lower the barriers to adoption, but I'm skeptical that lowering this particular barrier would make much difference at all. On the other hand, defining a mechanism for distributing routes whose semantics are much weaker than the one we have will lower the robustness of IPv6 and increase operational costs (for example, by forcing us to run VRRP forever because there is no fate sharing).

Lowering this particular barrier will certainly make IPv6 an easier concept for a number of enterprises.

Will having it instantaneously increase IPv6 adoption in the enterprise? Probably not.

Will failing to deploy it continue to impede IPv6 deployment in the enterprise? You bet.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 16:31:05 -0700

While unicasting of RAs can solve the problem, it does so at a much higher
administrative inconvenience than being able to use DHCPv6.

It also doesn't cover the additional functionality that would be gained from a
generic DHCPv6 Routing Information option rather than just a default router
ala DHCPv4.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Mar 2013 09:09:14 +0900

> Eventually, they run out of reasons.

Sometimes that happens, yes. But you're assuming that they think this is
necessary.

In many cases I've seen, reason Z is "we see no need to deploy IPv6". When
you ask them about IPv6 deployment, they prefer not to cite reason Z,
because that's a matter of opinion, and prefer to cite A, B, and C, which
are absolute blockers. If that's the case, all the other reasons are
removed, nothing happens anyway. Conversely, once Z is removed, suddenly
all the other reasons simply become engineering problems which then get
solved.

Again: our own enterprise network is a large deployment of IPv6, and we
didn't need DHCPv6 routing to do it. In fact, we don't even run DHCPv6
servers, which is good because it removes a maintenance burden.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Mar 2013 09:17:15 +0900

> generic DHCPv6 Routing Information option rather than just a default router

What functionality would such an option provide that cannot be provided
using the Route Information Option in the RA?

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 17:22:55 -0700

On Mar 27, 2013, at 5:17 PM, Lorenzo Colitti <[email-masked]> wrote:

> What functionality would such an option provide that cannot be provided using the Route Information Option in the RA? 

The combination of that functionality with deterministic and auditable client addressing?

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 17:21:38 -0700

On Mar 27, 2013, at 5:09 PM, Lorenzo Colitti <[email-masked]> wrote:

> Sometimes that happens, yes. But you're assuming that they think this is necessary.
> 
> In many cases I've seen, reason Z is "we see no need to deploy IPv6". When you ask them about IPv6 deployment, they prefer not to cite reason Z, because that's a matter of opinion, and prefer to cite A, B, and C, which are absolute blockers. If that's the case, all the other reasons are removed, nothing happens anyway. Conversely, once Z is removed, suddenly all the other reasons simply become engineering problems which then get solved.
> 
> Again: our own enterprise network is a large deployment of IPv6, and we didn't need DHCPv6 routing to do it. In fact, we don't even run DHCPv6 servers, which is good because it removes a maintenance burden.

A-Y may be seen as engineering problems which get solved, but I guarantee you that in at least some organizations, this will get solved by deploying some sort of routing functionality in DHCP. It really would be best if we standardized this at the IETF level.

What harm comes from having a routing information option documented for DHCPv6? Those organizations that don't feel they need it won't use it.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Mar 2013 09:31:47 +0900

> The combination of that functionality with deterministic and auditable

I don't understand that statement. You can have deterministic and auditable
addressing with DHCPv6 today, without having to use DHCPv6 to configure
routing.

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Mar 2013 09:51:31 +0900

> I'm seeing the possibility of no longer having to coordinate RFC 1918
> space across business units and partners as a compelling factor for
> adoption of IPv6.

yep, you just have to coordinate ula, a major advance.

---

From: Erik Kline <[email-masked]>
Date: Thu, 28 Mar 2013 10:12:37 +0900

> The combination of that functionality with deterministic and auditable

Unless you also use some Layer 2 security features you can only have a
vague squishy feeling of "auditable client addressing".  Of all the people
and organizations with whom I've discussed this only 1 or 2 actually do run
some kind link-level control (I'm sure there are others though).

For all the others, I strongly feel that we should focus on the far far
better solution of whatever it is that would make it easier for switches
and routers to log L2-L3 pairs (neighbor cache entries) as they come and
go.  That will allow people to audit devices that try to change IPv4
addresses as well.

---

From: Tom Perrine <[email-masked]>
Date: Wed, 27 Mar 2013 18:20:42 -0700

> yep, you just have to coordinate ula, a major advance.

Nope.  In our specific case, which is slightly different from the one I described, each business unit (all in different 
regions, or at least countries) is going to the local registry for PI space.

Some of the space will be used internally (and between the business units) and some will be consumer-facing.  All the 
units (in our case) are already multi-homed/multi-provider, so PI space is appropriate and this seemed the best way to 
just make the address space coordination problem go away.

The registries and global space are there for a reason, so we don't have to do that :-)

I've been watching the discussions of "how to deal with ULA space" and it seems that ULA just causes more headaches than 
necessary, *for an enterprise which is not an ISP*. I can't speak to the ISP issues, but for us, it seems like NAT, with 
all the problems that we're glad to finally be rid of (some day).

We're not an ISP, so no compelling reason to go anywhere near ULA.

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Mar 2013 10:29:08 +0900

> Nope.  In our specific case, which is slightly different from the one
> I described, each business unit (all in different regions, or at least
> countries) is going to the local registry for PI space.
> ...

96 more bits, no magic.  excellent.

> I've been watching the discussions of "how to deal with ULA space" 

nancy regan applies here

if we spent half as much energy on fixing the broken registry cartel as
we do complicating the technology to hack around it, the world would be
a better and simpler place a decade from now.

randy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Mar 2013 02:11:10 +0000

> Frankly, Apple would have done that a lot earlier if it hadn't been for all the IETF BS from people trying to block DHCPv6 in the first place.

As far as I know, the reason that Apple didn't release DHCPv6 until Mountain Lion is that Stuart Cheshire said "over my dead body," not that some evil cabal within the IETF pushed Apple not to do it.   And Stuart wasn't even against it for reasons relating to the conversation you guys are now having.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 21:44:50 -0700

> a better and simpler place a decade from now.

This isn't any of the 10+ lists I know of that are designated for that purpose.

I will point out that I haven't seen anything from you that even remotely approaches
a solution to issues with the alleged registry cartel on any of the aforementioned
lists.

(No, I do not think proposing to eliminate the policy process remotely approached
any such solution).

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 Mar 2013 21:45:21 -0700

> As far as I know, the reason that Apple didn't release DHCPv6 until Mountain Lion is that Stuart Cheshire said "over my dead body," not that some evil cabal within the IETF pushed Apple not to do i…

DHCPv6 support was added in Lion.

Owen

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 Mar 2013 01:06:17 -0700 (PDT)

> From: Lorenzo Colitti <[email-masked]>
>To: Owen DeLong <[email-masked]> 
>Cc: v6ops v6ops WG <[email-masked]> 
>Sent: Thursday, 28 March 2013 11:31 AM
>Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?
> 
>
>I don't understand that statement. You can have deterministic and auditable addressing with DHCPv6 today, without having to use DHCPv6 to configure routing.
>
>

Actually, stateful DHCPv6 will only provide auditability for the addresses it hands out. It won't capture information about hosts configured with static addresses, or hosts that ignore DHCPv6 and just use link-local addresses for on-link communication. Assuming this auditability is for security purposes, I'd think stateful DHCPv6 records would be quite inadequate. DHCPv4 has the same sorts of limitations.

The only way to record all addresses in use on an segment is to observe neighbor discovery messages, primarily DADs, and once learned, actively probe them using methods similar to NUD to detect when they disappear. If that is still not acceptable, then admission control via e.g. 802.1x, and then isolating authorised clients in their own virtual point-to-point link with the router (e.g. individual VLAN with individual /64) would be the way to control who attaches to the network, and what they can reach.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Mar 2013 17:12:12 +0900

On Thu, Mar 28, 2013 at 5:06 PM, Mark Smith <[email-masked]>wrote:

> Actually, stateful DHCPv6 will only provide auditability for the addresses
> it hands out. It won't capture information about hosts configured with
> static addresses, or hosts that ignore DHCPv6 and just use link-local
> addresses for on-link communication. Assuming this auditability is for
> security purposes, I'd think stateful DHCPv6 records would be quite
> inadequate. DHCPv4 has the same sorts of limitations.
>
>
> The only way to record all addresses in use on an segment is to observe
> neighbor discovery messages, primarily DADs, and once learned, actively
> probe them using methods similar to NUD to detect when they disappear. If
> that is still not acceptable, then admission control via e.g. 802.1x, and
> then isolating authorised clients in their own virtual point-to-point link
> with the router (e.g. individual VLAN with individual /64) would be the way
> to control who attaches to the network, and what they can reach.

What he said.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Mar 2013 08:21:48 +0000

>> to control who attaches to the network, and what they can reach.

There's this saying in successful retail operations that "the customer is
always right [even when wrong]."

If IT managers want to manage their networks using DHCPv6, they are right
[even if they're wrong].

What we need to analyse are the requirements for route configuration in
hosts; then we can figure out how to satisfy those requirements in both
RA-style and DHCPv6-style environments.

IMHO, of course.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Mar 2013 17:24:05 +0900

>  always right [even when wrong]."

But fortunately the IETF is not in the business of selling things?

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Thu, 28 Mar 2013 09:47:49 +0100

<sarcasm>
  How about using OpenFlow to push forwarding entries into said hosts?
  We would solve the "influence the host behavior" problem once and
  for all times ;)
</sarcasm>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Mar 2013 09:03:34 +0000

>   We would solve the "influence the host behavior" problem once and

I appreciate the sarcasm, but really, why should the IETF care?

Getting hosts to choose the best next-hop in a multi-interface,
multi-prefix, multi-protocol world is not a trivial problem.

    Brian

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Thu, 28 Mar 2013 10:13:18 +0100

> From: Brian E Carpenter [mailto:[email-masked]]
> 
> Getting hosts to choose the best next-hop in a multi-interface, multi-
> prefix, multi-protocol world is not a trivial problem.

And there will always be someone asking for the next knob, eventually resulting in a flowspec-like baroque construct. Maybe we should just repackage RFC 5575 in DHCPv6 options format? ;=)

Ivan

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Mar 2013 18:48:03 +0900

> But fortunately the IETF is not in the business of selling things?

as is stunningly demonstrated by the extent of ipv6 deployment

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Mar 2013 11:18:31 +0100 (CET)

On Thu, 28 Mar 2013, Mark Smith wrote:

> probe them using methods similar to NUD to detect when they disappear. 
> If that is still not acceptable, then admission control via e.g. 802.1x, 
> and then isolating authorised clients in their own virtual 
> point-to-point link with the router (e.g. individual VLAN with 
> individual /64) would be the way to control who attaches to the network, 
> and what they can reach.

I'd imagine doing similar to DHCP option 82 and using SAVI functionality 
in the L2 access layer actually gives good tracability.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 28 Mar 2013 10:26:45 +0000

The only way to record all addresses in use on an segment is to observe neighbor discovery messages, primarily DADs, and once learned, actively probe them using methods similar to NUD to

I agree. And just let the first hope router (or even switch) export the bindings to the DHCP server where this database almost always existed.

http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-tracking-00
http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-02

Cheers,
Rajiv

Sent from my Phone

On Mar 28, 2013, at 4:06 PM, "Mark Smith" <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
To: Owen DeLong <[email-masked]<mailto:[email-masked]>>
Cc: v6ops v6ops WG <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 28 March 2013 11:31 AM
Subject: Re: [v6ops] IT'S MOSTLY A SOLVED PROBLEM - Fw: Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?

On Thu, Mar 28, 2013 at 9:22 AM, Owen DeLong <[email-masked]<mailto:[email-masked]>> wrote:

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

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

---

From: Ray Hunter <[email-masked]>
Date: Thu, 28 Mar 2013 11:54:33 +0100

> RA-style and DHCPv6-style environments.
Agreed.

If you just count the number of current drafts in various WGs that
incorporate distribution of policy or other information from a
router/infrastructure to a mobile end node, we clearly need a generic
mechanism for that. I frankly don't care about the details of the
transport, but no-one can deny that RA has very limited transmission
capacity, which will be used up very quickly once policy tables have to
be distributed. It also places a hard link between upgrading all infra
and all end nodes in order to introduce anything new.

Putting any technical arguments aside (this is after all supposedly more
of an operations list) if I go to the CFO and say, hey we've got this
great feature and we can implement it by:
1) buying new switch hardware (write off period 7-12 years and we've
just upgraded)
2) upgrading the software of all of our switches and all of our end
nodes before we can roll out the first feature company-wide to support
travelling users (3-5 year investment cycle, or 1 year project to
upgrade everything)
3) Investing a small delta in a generic transport for hand off of
management information between our infra and our end nodes (where the
transport is configured once by the switch operator and the end node
operator, and where the content of the management information is
centrally managed by a small team responsible for end node services, and
by the way we already have this IPAM solution in place for IPv4 so we
can leverage that, and the trust solution is also in place via Active
Directory so we can leverage that too)
4) sticking with IPv4 and sticking plasters and proxy.pac configs etc.
but having to increase team size to stay on top of changes or not being
able to perform M&A or expansion.

I know which one he will choose.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Mar 2013 14:59:26 +0000

> DHCPv6 support was added in Lion.

I thought stateful didn't come in until Mountain Lion, but it doesn't really matter—the point is that it wasn't the IETF that delayed this; it was an internal architectural debate at Apple; a debate that actually had nothing to do with the question of default routes in DHCP.

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 28 Mar 2013 13:44:04 -0400

> It may be that they tell you about X. When you eliminate X, they tell you

Or it may be that they don't even figure out that Y is a problem until they
can move beyond X.  That is not uncommon.

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Mar 2013 21:28:35 -0700

> I thought stateful didn't come in until Mountain Lion, but it doesn't really matter—the point is that it wasn't the IETF that delayed this; it was an internal architectural debate at Apple; a debat…

Actually it's a great example of how one (or a few) individual(s) can 
stall progress due to their dogmatic beliefs.

Doug

---

From: Philipp Kern <[email-masked]>
Date: Wed, 27 Mar 2013 17:33:18 +0100

Randy,

> the nat4444 highway.  hope you like living in hell.  i don't and i don't

this missing feature has not come up in any of my discussions with (potential)
users at all. Most are confused about DUIDs and no MAC-based addressing, though.

Please don't make this issue as big as an elephant while it really isn't.

Kind regards
Philipp Kern

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 10:35:12 -0700

> Actually, stateful DHCPv6 will only provide auditability for the addresses it hands out. It won't capture information about hosts configured with static addresses, or hosts that ignore DHCPv6 and j…

Unless the DHCP server is tied into your network admission controls.

> The only way to record all addresses in use on an segment is to observe neighbor discovery messages, primarily DADs, and once learned, actively probe them using methods similar to NUD to detect whe…

Yep

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 10:39:31 -0700

On Mar 28, 2013, at 01:24 , Lorenzo Colitti <[email-masked]> wrote:

> On Thu, Mar 28, 2013 at 5:21 PM, Brian E Carpenter <[email-masked]> wrote:

Herein lies the fundamental flaw in the assumptions being made by the our way or the highway thinkers in the IETF.

The IETF may not be in the business of exchanging products for money. That does not mean that sales is not an important part of what the IETF does.

If you think of sales not as merely the exchange of goods and services for money, but, as the process of gaining market acceptance of your output, then, the sales is absolutely critical to continued IETF relevance.

As I said, routing information in DHCPv6 will happen. Either within the IETF or without it. Everyone is better off if we standardize it within the IETF and don't end up with competing multiple disparate implementations.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 29 Mar 2013 13:06:33 -0700

> users at all. Most are confused about DUIDs and no MAC-based addressing, though.

I'm happy for you. It has come up in many of my discussions with potential users.

DUIDs vs MAC comes up frequently too. Usually that's settled pretty quickly by
explaining the history of Ethernet Cards and wanting an address that survived
replacement of the card.

> Please don't make this issue as big as an elephant while it really isn't.

It's a big issue. Depending on how you map virtual size onto real size, it may be
larger or smaller than an elephant.

YMMV.

Owen

---

From: Doug Barton <[email-masked]>
Date: Fri, 29 Mar 2013 23:56:57 -0700

On 03/27/2013 12:48 PM, Iljitsch van Beijnum wrote:
>>> If someone really has a special need in this area, it's probably
>>> a better idea to install a routing daemon on their hosts rather
>>> than expect ALL hosts connected to the internet to implement
>>> something new that comes with additional failure modes.
>
>> Completely unrealistic.
>
> You think it's less realistic to install some software under your own
> control on devices under your own control than getting IETF rough
> consensus after you couldn't get it for (at least) four years, and
> then wait for third parties with no skin in the game to implement it
> in their software?

If there is market demand the "third parties with no skin in the game" 
will implement it, just like they do every other aspect of the protocol. 
And no, I don't think "Here is this great protocol, but in order to 
manage it in a way similar to what you already know and have structures 
for you have to install stuff on every host" is in any way realistic. 
It's much more realistic that they'll skip it altogether (kind of like 
they are doing now).

>> And what some people around here seem to be missing is that there
>> is absolutely no motivation for them to do so. In fact, there is
>> little to no incentive for them to deploy v6 inside an end-user
>> network at all right now, and there isn't going to be any time in
>> the next 5 years for sure, and likely for another decade if not
>> longer.
>
> IPv4 is a profoundly flawed protocol. But we've used it for 30 years
> now. We'll have to use IPv6 for longer than that in all likelihood.
> So it's important to refrain from importing those IPv4 flaws in IPv6
> as much as we can.

Yeah, I get that is how you feel. However there is a lot of opinion on 
the side of "things that are already working should be migrated."

> For that reason, when a whole bunch of protocol designers tell you a
> specific way to implement a feature you like is a bad way to do it,
> it might be useful to listen to them, and perhaps explore different
> ways to get that same feature.

OTOH, when a whole bunch of protocol designers have spent way too much 
time in their ivory towers and refuse to listen to needs of the people 
who would be implementing said protocol, it might be useful if they 
listened to someone who didn't live in the echo chamber with them. See 
what I did there? :)

> So far you haven't bothered to address my suggestion of replacing a
> proposed DHCPv6 default router option with a DHCPv6 option that lets
> a host select the desired default router from the ones available
> through RAs.

Um, yeah, no. One of the key goals of a robust DHCPv6 implementation is 
not having to use RAs at all. What you're proposing not only adds 
complexity, it has the extra side benefit of not actually meeting that 
goal.

Doug

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Mar 2013 08:11:04 +0100

On 30 mrt 2013, at 7:56, Doug Barton <[email-masked]> wrote:

> One of the key goals of a robust DHCPv6 implementation is not having to use RAs at all. What you're proposing not only adds complexity, it has the extra side benefit of not actually meeting that goal.

But without RAs, how do you see M=1 so you start up your DHCPv6 client?

Oh wait, you want to run your DHCPv6 client always, even if there is no M=1. This means that networks will see tons of multicasts looking for a DHCPv6 server, retransmitted at infinitum if there is no DHCPv6 server, wasting precious airtime on wireless networks where multicasts are sent at a very low rate because for multicasts, there are no acknowledgments and therefore they must be sent at a very low bitrate to make a chance to get through.

No thanks.

Iljitsch

---

From: Doug Barton <[email-masked]>
Date: Sat, 30 Mar 2013 00:23:49 -0700

On 03/30/2013 12:11 AM, Iljitsch van Beijnum wrote:
>> One of the key goals of a robust DHCPv6 implementation is not
>> having to use RAs at all. What you're proposing not only adds
>> complexity, it has the extra side benefit of not actually meeting
>> that goal.
>

I've seen plenty of discussion about how the semantics of the various 
combinations of M and O bits are not really well understood, less well 
implemented, and open for discussion.

> Oh wait, you want to run your DHCPv6 client always, even if there is
> no M=1.

Didn't say that. Are you saying that someone would run an IPv6 network 
with no RA, AND no DHCPv6?

I think it's obvious that any implementation of a DHCPv6 routing option 
would require a decision matrix which takes into consideration the 
presence and absence of RA, presence/absence of M/O bits, lack of 
response from a DHCP server, etc. DHCPv4 already has progressive 
backoff, including eventually giving up. It's not hard to imagine doing 
the same for v6.

In other words, this can be done in a way that takes everyone's needs 
into account. Stop standing in the way.

Doug

---

From: [email-masked]
Date: Sat, 30 Mar 2013 08:31:07 +0100 (CET)

> Oh wait, you want to run your DHCPv6 client always, even if there is no M=1. This means that networks will see tons of multicasts looking for a DHCPv6 server, retransmitted at infinitum if there is…

How is this worse than current DHCPv4 client behavior?

Steinar Haug, AS 2116

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Mar 2013 08:33:38 +0100

On 30 mrt 2013, at 8:23, Doug Barton <[email-masked]> wrote:

> I've seen plenty of discussion about how the semantics of the various combinations of M and O bits are not really well understood, less well implemented, and open for discussion.

So now you want:

> I think it's obvious that any implementation of a DHCPv6 routing option would require a decision matrix which takes into consideration the presence and absence of RA, presence/absence of M/O bits, lack of response from a DHCP server, etc.

> In other words, this can be done in a way that takes everyone's needs into account. Stop standing in the way.

We finally are in a situation where stateless autoconfiguration and DHCPv6 work reasonably well together in the real world, and now you want to mess that up for all of us just because a few people find it inconvenient to install special purpose software on hosts they want to have a special purpose configuration.

If me standing in the way prevents that from happening, I'm not going anywhere.

But isn't there a slight chance you're giving me too much credit here?

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Mar 2013 08:42:01 +0100

On 30 mrt 2013, at 8:31, [email-masked] wrote:

>>> you want to run your DHCPv6 client always, even if there is no M=1. This means that networks will see tons of multicasts looking for a DHCPv6 server, retransmitted at infinitum if there is no DHCPv6 server, wasting precious airtime on wireless networks where multicasts are sent at a very low rate

> How is this worse than current DHCPv4 client behavior?

In the IPv4 world, DHCP is the only game in town. So it's reasonable to assume the presence of a DHCP server. In the IPv4 world, there can be stateless autoconfig or DHCPv6 for address assignment. If hosts are going to solicit an address through DHCPv6 that means everyone has to run a DHCPv6 server to soak up those requests, even the people who just want to use stateless autoconfiguration.

This would have been a bad idea in 1998, but it's an even worse idea now with IPv6 implemented widely already.

Iljitsch

---

From: Doug Barton <[email-masked]>
Date: Sat, 30 Mar 2013 00:50:35 -0700

On 03/30/2013 12:33 AM, Iljitsch van Beijnum wrote:
> We finally are in a situation where stateless autoconfiguration and
> DHCPv6 work reasonably well together in the real world

... except for the parts where various critical client configuration 
options aren't available via RA, and lack of robust DHCP is hindering 
deployment.

> and now you
> want to mess that up for all of us just because a few people find it
> inconvenient to install special purpose software on hosts they want
> to have a special purpose configuration.

Your definition of "special purpose" is what most network operators 
refer to as "how we do things."

I've never said I want RA to go away. I think for the limited purpose it 
was designed for, it's a great tool. When RA was designed 15 years (or 
so) ago DHCPv4 was still in its early days, and certainly hadn't "won 
the day" in terms of being ubiquitous, or even particularly mature.

However, things changed. DHCPv4 got better, and got implemented pretty 
much everywhere when it comes to end-user deployments. The whole idea of 
stateless autoconfiguration is interesting, and has a place for "dumb" 
endpoints that just need an address and connectivity. But for typical 
end-user host networks it shouldn't be mandatory.

Doug

---

From: Tarko Tikan <[email-masked]>
Date: Sat, 30 Mar 2013 10:09:01 +0200

hey,

> implemented, and open for discussion.

Yes, it's broken. No way to influence if end host/router should do IA_NA 
or IA_PD or both.

There is no correct config if you want to provide PD only and run your 
HGW uplinks unnumbered. Sure, set M, some routers will not start DHCPv6 
without it at all, others will. Still have to manually configure routers 
to make PD only request. And you will still get NA requests from 
misconfigured routers or people attaching PCs directly to the uplinks.

As a network provider, mess around RA+DHCPv6 is much worse than putting 
routing information into DHCPv6 and killing RA altogether.

-- 
tarko

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Mar 2013 08:54:18 +0000

> In the IPv4 world, DHCP is the only game in town. So it's reasonable to assume the presence of a DHCP server. In the IPv4 world, there can be stateless autoconfig or DHCPv6 for address assignment.…

I think people should look at draft-liu-bonica-dhcpv6-slaac-problem,
because it really is time to resolve this issue. And it's
orthogonal to the default/source route issue.

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sat, 30 Mar 2013 09:44:02 +0000

> Sent: Saturday, March 30, 2013 4:54 PM
> To: Iljitsch van Beijnum
> Cc: [email-masked] WG
> Subject: [v6ops] dhcpv6-slaac-problem [was Interest in DHCPv6
> Route/DefRouter/Src-basedRoute configuration to Client?]
> 
> >>>> you want to run your DHCPv6 client always, even if there is no M=1.
> This means that networks will see tons of multicasts looking for a DHCPv6
> server, retransmitted at infinitum if there is no DHCPv6 server, wasting
> precious airtime on wireless networks where multicasts are sent at a very
> low rate
> >
> > In the IPv4 world, DHCP is the only game in town. So it's reasonable to
> assume the presence of a DHCP server. In the IPv4 world, there can be
> stateless autoconfig or DHCPv6 for address assignment. If hosts are going to
> solicit an address through DHCPv6 that means everyone has to run a DHCPv6
> server to soak up those requests, even the people who just want to use
> stateless autoconfiguration.
> 

[Bing] Hi, Brian, thank you mentioned this. Hope more people could notice the problem. 
Let me to summarize several important points of the draft here: 
- at initial state, Win7 would start DHCPv6 solicit if no RA received, while Linux/MAC won't start DHCPv6 unless received M=1
- the hosts configured by SLAAC first, and then M changed from 0 to 1, Win7 would initiate DHCPv6 along with SLAAC; Linux/MAC did nothing
- the hosts configured by DHCPv6 first, and then M changed from 1 to 0, Win7 would release DHCPv6 address while Linux/MAC did nothing
These different behaviors would be problematic especially when renumbering.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Mar 2013 10:44:32 +0100

> orthogonal to the default/source route issue.

That draft mainly looks at what happens when the different bits go from 1 to 0. While it's useful to clean up the differences in behavior for that case, all of that seems largely orthogonal to the issues we were discussing previously.

Other than the above, my vote is for leaving well enough alone.

But if we collectively decide that the status quo is insufficient, we need to make changes in the right way, not haphazardly throw new DHCP options against the wall and see which ones stick.

Going back to first principle, if we want to support both some form of stateless autoconfiguration as well as some form of centrally managed configuration, it makes sense that hosts send one message that can initiate either or both rather than have two protocols that operate independently. This saves on messages exchanged, timeouts incurred and client-side guessing required.

Fortunately, it looks like the IPv6 designers knew what they were doing (for the most part) back in the day, and allowed pretty much every message to have options. So what we could do is put a DHCPv6 request inside a router solicitation message, and thus have a single message that can initiate both stateless autoconfig and DHCPv6. We now also have a clean upgrade path: old hosts don't include the DHCPv6 request and get back a normal RA (with A=1 and/or M=1 as desired). The same is true for new hosts that talk to old routers. But when a new host talks to a new router, we get to throw out all the old behavior. Then, for instance, the router can send back a regular RA, or relay the DHCPv6 message to a DHCPv6 server, which can take it from there.

Iljitsch

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 Mar 2013 14:10:41 +0000

> Fortunately, it looks like the IPv6 designers knew what they were doing (for the most part) back in the day, and allowed pretty much every message to have options. So what we could do is put a DHCP…

Interesting.   And on the way back (since the relay chain plays in both directions) the response could come back to the host as a DHCPv6 message encapsulated in an RA that also contained prefix information, and now you have fate sharing and DHCP in a single exchange.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 30 Mar 2013 15:15:52 +0100

Le 30/03/2013 15:10, Ted Lemon a écrit :
>> Fortunately, it looks like the IPv6 designers knew what they were
>> doing (for the most part) back in the day, and allowed pretty much
>> every message to have options. So what we could do is put a DHCPv6
>> request inside a router solicitation message, and thus have a
>> single message that can initiate both stateless autoconfig and
>> DHCPv6. We now also have a clean upgrade path: old hosts don't
>> include the DHCPv6 request and get back a normal RA (with A=1
>> and/or M=1 as desired). The same is true for new hosts that talk to
>> old routers. But when a new host talks to a new router, we get to
>> throw out all the old behavior. Then, for instance, the router can
>> send back a regular RA, or relay the DHCPv6 message to a DHCPv6
>> server, which can take it from there.
>
> Interesting.   And on the way back (since the relay chain plays in
> both directions) the response could come back to the host as a DHCPv6
> message encapsulated in an RA that also contained prefix information,
> and now you have fate sharing and DHCP in a single exchange.

I think too it is interesting.

The message encoding ('encapsulate DHCP messages - Solicit in RS, Adv in 
RA, etc.) is a matter how to encode.  One may also encode the same 
behaviour without really encapsulating IP in IP.  Or a middle ground 
somewhere.

(we approached a similar thing when we tried to realize Prefix 
Delegation with RS/RA - engineered the typical PD operations down into 
RS/RA messages - draft-kaiser-nd-pd-01)

Alex

---

From: Philipp Kern <[email-masked]>
Date: Sat, 30 Mar 2013 12:05:45 +0100

> explaining the history of Ethernet Cards and wanting an address that survived

True. But it so utterly fails in multiboot and initially installation /
provisioning scenarios that it isn't funny. So what should an installer do?
Ubuntu did DUID-LL, but that's not really allowed in terms of the RFC. Maybe
one should pass a fixed DUID in using PXE.

People want the same address for the machine regardless which OS runs. If
machines shipped with an NVRAM to use for it… Maybe UEFI will solve everything
for us, but so far it did not, especially not across OS vendors.

Kind regards
Philipp Kern

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 Mar 2013 19:13:47 +0000

WARNING: bad headers - Improper use of control character (char 0D hex):
 References: [email-masked]>\r <2013032716331[...]

Subject: Re: [v6ops] Interest in DHCPv6 Route/DefRouter/Src-basedRoute configuration to Client?
From: Ted Lemon <[email-masked]>
To: Philipp Kern <[email-masked]>
Cc: Owen DeLong <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 30 Mar 2013 19:13:47 +0000

> one should pass a fixed DUID in using PXE.

We're hoping that this will finally put the problem to bed:

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/

Should be an RFC soon.   Put it in your RFPs and RFQs as a requirement.