Subject: [dhcwg] DHCPv6 router option

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Mar 2009 16:38:35 +0100

I very strongly disagree with draft-droms-dhc-dhcpv6-default- 
router-00.txt in its current form.

The ability to put a random address in DHCPv6 that is supposed to be a  
router, but which in actuality may or may not be a working router is a  
huge step backwards from the current situation where routers  
themselves announce their existance and therefore there is a  
reasonable expectation that they are, in fact, working routers.

What I suggest is that you change the draft such that router  
advertisements are still required, but the DHCPv6 option indicates  
which of the routers that advertise their presence a host should use.

I'm also missing any discussion about dead neighbor detection, which  
would normally make a host select a different default router.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Mar 2009 09:24:38 -0700

On Wed, Mar 11, 2009 at 04:38:35PM +0100, Iljitsch van Beijnum wrote:
> What I suggest is that you change the draft such that router advertisements 
> are still required, but the DHCPv6 option indicates which of the routers 
> that advertise their presence a host should use.

I oppose this change, as it seems to be ignoring requirements the
draft includes in its own text.  Seeking to change requirements
rather than to provide solutions.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: [email-masked]
Date: Wed, 11 Mar 2009 17:53:55 +0100 (CET)

> reasonable expectation that they are, in fact, working routers.

I strongly disagree with your disagreement.

The Introduction in the draft captures my needs very well:

"In some deployments, however, there is a strong desire not to use
Router Advertisements at all and to perform all configuration via DHCP
[RFC3315].  For example, network administration may want to control
all host configuration through a single centralized DHCP service in
order to more closely manage which addresses are assigned and in use."

> which of the routers that advertise their presence a host should use.

No. The whole point here is centralized administration which ties in
with various other operational support systems. The DHCP server should
control which default router the DHCP client should use, *not* the
router.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Mar 2009 17:59:52 +0100

> The Introduction in the draft captures my needs very well:

That's nice, but your needs don't give you a free pass to make my  
network less reliable.

> The DHCP server should

Stated like this, I can go along with that.

That's why I suggested having the DHCPv6 server tell the client WHICH  
of the available routers to select, but if and only if that router  
announces its presence.

This way, pointing towards a black hole and hosts losing connectivity  
can't happen.

---

From: [email-masked]
Date: Wed, 11 Mar 2009 18:06:25 +0100 (CET)

> That's nice, but your needs don't give you a free pass to make my  

Clearly not - but then nobody says *you* have to use DHCP with this
option. All I am saying is that I want to use it for *my* customers.

> This way, pointing towards a black hole and hosts losing connectivity  

I am considerably more worried about a possible inconsistency between
the router and the DHCP server, than pointing the client towards a
black hole. It is not a problem for us today, and I see no reason why
it should be a bigger problem with IPv6.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Mar 2009 18:17:12 +0100

> it should be a bigger problem with IPv6.

There are problems with DHCP in IPv4 all the time, especially for non- 
expert users. Having routers announce their own presence was one of  
the things that make IPv6 more reliable than IPv4. Throwing away that  
feature is completely unacceptable to me, so expect unrelenting  
opposition if that is what you intend to standardize here.

However, the underlying need here is for administrators to make sure  
that the hosts send their traffic to the right router, and don't just  
randomly select any address for which there are RAs. This need is met  
by allowing the DHCPv6 server, if present, to impose the selection. So  
I don't see how this change takes away anything from the intended use.  
This just requires setting up the designated router to send out RAs  
(easy), without requiring making all other routers stop sending RAs  
(hard).

Yes, this means that you still need to have RAs in your network. In an  
ideal world you would be able to get rid of those if you don't want  
them. But this isn't an ideal world, and RAs don't get in the way in  
any way that I can see, so having to live with this is more than worth  
having the additional robustness that hosts can still talk to the rest  
of the network if the DHCP server dies or someone fatfingers its config.

---

From: [email-masked]
Date: Wed, 11 Mar 2009 18:41:27 +0100 (CET)

> the things that make IPv6 more reliable than IPv4.

Given the current deployment of IPv6, I find it very hard to make any
such statement about the reliability of IPv6 vs IPv4. But that is a
different discussion.

> Throwing away that  

Yes, some of us really would like to operate networks without customer-
facing RAs for our DHCP customers.

> of the network if the DHCP server dies or someone fatfingers its config.

I believe this is one of the key disagreements. In my world, finding out
(and fixing) the fatfingered configuration or the dead DHCP server is far
more important than connectivity for one or a few customers.

If one customer loses connectivity, as you have suggested, then calls
in to customer support, and this helps us find and fix the problem more
quickly - this is a *good* thing, not a bad one!

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Mar 2009 19:33:51 +0100

On 11 mrt 2009, at 19:13, Howard, Lee wrote:

> One predictable solution is to have the client
> request a default router from DHCP if not learned through RA.  I
> haven't worked through the timing there; possible race condition or
> delay in configuration.

If a network runs without RAs then clients would be forced ot ask for  
this option, if clients ask for it administrators will turn of RAs...  
This pushes towards the situation where clients must enable all  
options, which is rather suboptimal.

How about this:

If the DHCPv6 server says to use an address, then:

- if there are no RAs, use the address
- if there are RAs that include the address, use the address
- if there are RAs but they don't include the address, use the RAs

However, this doesn't solve the issue for clients to decide when to  
use DHCPv6. Normally the MO bits in RAs tell them to, but without RAs  
no MO bits.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Mar 2009 11:37:14 -0700

> I strongly disagree with your disagreement.

This is a major hot-button issue.   People have extremely strong  
opinions about it.   It happens that although you and Iljitsch  
disagree on what to do, you both have valid points.   At the same  
time, you appear to be talking past each other.

What appears to be worrying Iljitsch, which you do not appear to be  
concerned about, is that if a DHCPv6 client is receptive to this  
option, it will trust it even when it is wrong, not just on your  
network but on his.   So adoption of this option affects Iljitsch just  
as much as it affects you - he can't "opt out."

Similarly, your requirement, which Iljitsch does not agree with, is  
that on some networks, managing what gets sent in RAs is a lot more  
work than managing what gets sent by the DHCP server.   DHCP provides  
you with a central control point, whereas RAs are necessarily  
configured in the router.

As I say, I don't know if you can reach any kind of rapprochement, but  
I think this is the heart of your disagreement, and I think that this  
conflict is well understood by the working group.   It would be nice  
if there were some way for Iljitsch to opt out that still allowed you  
to get what you want, but I'm not sure that there is, which is what  
makes this a contentious discussion.

---

From: [email-masked]
Date: Wed, 11 Mar 2009 19:43:40 +0100 (CET)

> use DHCPv6. Normally the MO bits in RAs tell them to, but without RAs  

I would prefer to be able to operate entirely without RA. However,
I can live with RA which only contains the MO bits and no prefix
information.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Mar 2009 11:46:20 -0700

On Wed, Mar 11, 2009 at 11:37:14AM -0700, Ted Lemon wrote:
> concerned about, is that if a DHCPv6 client is receptive to this option, it 
> will trust it even when it is wrong, not just on your network but on his.   
> So adoption of this option affects Iljitsch just as much as it affects you 
> - he can't "opt out."

He absolutely can, don't send the option.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Mar 2009 19:47:14 +0100

> I can live with RA which only contains the MO bits and no prefix

That's not a problem.

If you then also set the RA lifetime to 0 hosts won't use the router  
as a default router.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 11 Mar 2009 11:59:36 -0700

On Wed, Mar 11, 2009 at 11:51:52AM -0700, Ted Lemon wrote:
> On Mar 11, 2009, at 11:46 AM, David W. Hankins wrote:
> Right, but the rogue DHCPv6 server on his net still can.

And the rogue RA on the DHCPv6 network still can.  What is your
point?  People need to be concerned about security?

---

From: [email-masked]
Date: Wed, 11 Mar 2009 20:01:18 +0100 (CET)

> If you then also set the RA lifetime to 0 hosts won't use the router  

Not quite what I was looking for, I'm afraid.

- As mentioned I'd prefer to operate entirely without RA, getting all
the information from DHCP.

- As an alternative: Getting all the info from DHCP (including prefix
info) but letting the router which the prefix points to send RAs with
MO bits only. Having this router send RA with lifetime 0 would then
obviously not work...

- Lowest on my preferred list: Having the router send RA, with prefix
information *but* where the router's RA prefix is snooped from the
DHCP traffic (in my case the router is always a DHCP relay, so picking
up the prefix may not be much extra work).

---

From: Frank Sweetser <[email-masked]>
Date: Wed, 11 Mar 2009 15:05:33 -0400

> as much as it affects you - he can't "opt out."

Just to throw some more sand in the gears, there's also no guarantee that the
RAs your clients are hearing are usable for them.  Just last week, I had all
IPv6 enabled clients in one subnet lose connectivity.  After some digging
around, it turned out that an XP box had began sending RAs, advertising its
link local address as a default gateway.  Once you allow fumble-fingered
admins into the equation, not much is safe.

When SOHO devices from Linksys and Netgear start appearing with IPv6 support,
it's inevitable that those of us running EDU networks with dorms will have to
deal with students plugging them in the wrong way around, just as they have
been doing for many years.  While this may be a "new" problem in that it uses
RA to break the subnet, it's really not different from using DHCPv4 or ARP.  I
strongly suspect that in the end the switch vendors are going to have to
create v6 analogues to the ARP and DHCP rogue server prevention features
they've already implemented for v4.

> configured in the router.

To expand on this point more, if you have multiple routers on a subnet, it's
quite conceivable that different administrative categories of clients should
be directed as specific routers.  This could be for QoS, bandwidth costs,
quarantine networks, or other odd site specific requirements.  Sending a
router list via DHCP would allow for an administrator to customize the router
list per client, something which isn't possible to do when the client is
simply rounding up RAs.

> makes this a contentious discussion.

A couple of other posts have suggested ways in which the MO bits can be used
to effective tell clients not to use the RA to set up the default gateway.  At
least from my point of view (I would prefer a DHCP only method in my network,
though I can easily see how using RA would have advantages elsewhere) that
would be perfectly acceptable, as it means that I can effectively control
which data source my clients are using.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Mar 2009 12:10:39 -0700

> point?  People need to be concerned about security?

My point is that neither position is a clear win - both have problems.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Mar 2009 22:58:58 -0400

Iljitsch - by "RA lifetime" do you mean "Router Lifetime" field in an  
RA?

If so, that is one of the ways in which we intended to signal that the  
RA does not carry any default router information.

To be clear, we should probably add text to that effect to the doc.   
In addition, we need to add a little more text treating "Router  
Lifetime" as a special case; if the existing text is interpreted  
literally, setting the "Router Lifetime" to 0 in an RA and non-zero in  
the DHCP option results in the host receiving conflicting information  
about that router from the RA and from DHCP.  So, we also need text  
like "If the host chooses to ask for default router information from  
the DHCP server when it receives no default router information from  
RAs, the host MUST ignore the Router Lifetime values in the RAs and  
MUST use the Router Lifetime information from the DHCP options.  The  
presence of the Router Lifetime values in RAs and DHCP options is not  
considered to be a conflict resulting from misconfiguration as  
described in section XXX."

If I understand the discussion Ted summarized as having no good  
solution, the problem is about signaling the host to use RAs or DHCP,  
and the host has to explicitly request the default router and prefixes  
from the DHCP server by including those options in the ORO.  Can the  
host use these rules:

* if it receives no default routers with lifetime > 0, add the default  
router option to the ORO
* if it receives no prefixes, add the prefixes option to the ORO

If I've got this right, the rules also work in the case when the host  
receives no RAs, because it will have receives no default routers or  
prefixes.

- Ralph

On Mar 11, 2009, at 2:47 PM 3/11/09, Iljitsch van Beijnum wrote:

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

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 12 Mar 2009 10:47:37 +0100 (CET)

On Wed, 11 Mar 2009, Ted Lemon wrote:

>
> Similarly, your requirement, which Iljitsch does not agree with, is that on 
> some networks, managing what gets sent in RAs is a lot more work than 
> managing what gets sent by the DHCP server.   DHCP provides you with a 
> central control point, whereas RAs are necessarily configured in the router.

I think the opposite is true is sense of ease of management:
- You have to configure router anyway to have connectivity. Adding RA 
parameters is rather easy.
- Setting up DHCP server and maintaining is requires extra work, however 
you might have tighter control which is very important in various 
environment.

I strongly support adding prefix information options. Tim Chown, Stig 
Venaas and me wrote last summer a half baked draft which we did not finish 
due to lack of time. For the default router option I am not so convinced: 
We have to find a solution that not breaking anything existing and 
fulfilling requirements of DHCP controlled environment.

Best Regard,
 		Janos Mohacsi

---

From: [email-masked]
Date: Thu, 12 Mar 2009 11:13:59 +0100 (CET)

> parameters is rather easy.

Here is where we see the difference in scale. Setting up a router with
RA for one interface is easy. Doing the same for 10.000 interfaces does
not scale. Doing it on the DHCP server, and letting the router do the
rest "automagically", *based on information from the DHCP server", gives
us the necessary scaling on the router.

> you might have tighter control which is very important in various 

The DHCP infrastructure is already in place and ties in with other
operational support systems.

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 12 Mar 2009 11:20:27 +0100 (CET)

> us the necessary scaling on the router.

You have to configure the dhcp proxy option on the same amount of 
interfaces.

> operational support systems.

Can you mention - probably offlist - one system which is integrating 
DHCPv4 (existing DHCP infrastructure), with DHCPv6 (infratructure under 
deployment). For example we are operating one DHCP for IPv4 and a 
different one for DHCPv6. Best Regards,

 		Janos Mohacsi

---

From: [email-masked]
Date: Thu, 12 Mar 2009 11:34:56 +0100 (CET)

> You have to configure the dhcp proxy option on the same amount of 

For our routers this is either implicit (global configuration) or it is
a one-line explicit configuration (turn on DHCP relay for subinterfaces
of physical interfaces x, y, z).

> different one for DHCPv6. Best Regards,

We certainly expect to use the same DHCP servers for IPv4 and IPv6.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Mar 2009 07:14:00 -0400

Ted - I agree with you: we have two opposing points of view, both of  
which have been fully (exhaustively?) articulated in previous  
discussions of this issue.

The way in which we can have a constructive discussion now is to focus  
on the technical issues in the following way...

Hypothesize that both forms of host configuration are available: a  
list of default routers and on-link prefixes can be delivered through  
either RAs or DHCP.  Now, consider your favorite way to configure  
those hosts, and consider the devices that have already been  
deployed.  Review the spec to see if you can configure hosts the way  
you want to, considering any effects of other methods of configuration  
and existing deployment scenarios.  Let us know if you can run your  
network the way you want to run your network, according to the spec.   
Or, let us know what's missing, or how the spec interferes with how  
you wan to run your network.

For example, the spec shouldn't (I would argue pretty clearly MUST  
NOT) make any changes to the way currently deployed networks are run.   
So, networks using RAs to supply default routers and prefixes MUST NOT  
be affected by any new DHCP options and semantics.

Conversely, to meet the requirements in the spec, the spec should  
allow for operation with an RA configuration that carries no router or  
prefix information and for operation with no RAs at all.

The latest rev of the doc does not meet these requirements because it  
doesn't describe how the client decides which configuration mechanism  
to use.  I proposed some rules:

These rules are still inadequate;  for example, suppose the network  
admin requires that the host use DHCP, and a device on the link sends  
a rogue RA with default router and prefix information.  This problem  
is impossible to solve completely through the use of just ND and  
DHCP.  We can optimize network behavior; here are a couple of ideas:

* "RA guard" to filter and limit the scope of misconfigured RAs
* a DHCP option, to be sent with the initial DHCP message exchange,  
signaling the host to ignore all future RAs

We need to continue the discussion; let's focus on how to allow both  
methods of configuration to coexist.

- Ralph

On Mar 11, 2009, at 2:37 PM 3/11/09, Ted Lemon wrote:

> network but on his.   So adoption of this option affects Iljitsch  
> just as much as it affects you - he can't "opt out."
>
> work than managing what gets sent by the DHCP server.   DHCP  
> provides you with a central control point, whereas RAs are  
> necessarily configured in the router.
>
> As I say, I don't know if you can reach any kind of rapprochement,  
> but I think this is the heart of your disagreement, and I think that  
> this conflict is well understood by the working group.   It would be  
> nice if there were some way for Iljitsch to opt out that still  
> allowed you to get what you want, but I'm not sure that there is,  
> which is what makes this a contentious discussion.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Mar 2009 10:07:32 -0400

While we can't do anything about existing hosts that don't make use of
these new options, it seems to me that ideally people may want three
modes (for hosts that support these new options):

1. Use RAs. Hence if a client includes the options in the ORO, the
server SHOULD NOT include these options in the response. This is what we
have today.
2. Use DHCP. Whether RAs are sent or not, the hosts should ignore RAs
and only make use of the information provided via DHCP.
3. Use both? Perhaps 'prefer' the information provided via DHCP, perhaps
not?

This draft states:

   Conflicting or overlapping information received through Router
   Advertisements and through DHCP is considered a misconfiguration and
   is out-of-scope of this document.  For example, if a host receives a
   list of default routers through DHCP and a Router Advertisement with
   a non-zero lifetime, the result is undefined.

Which makes 2 (when RAs exist with overlapping information) and 3 out of
scope? This is probably what is causing much of the problem as I think
some want to use this to avoid rogue RAs (putting aside whether DHCP is
any more secure than RAs).

I also think that expecting to live in a clean world (whether EITHER RAs
OR DHCP are ONLY used) is unrealistic.

Therefore, I think the draft needs to address this as it has little
benefit to just declare this as "out-of-scope". Perhaps it can be
addressed in a separate document, but I don't think we should advance
this work until that document is also available.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Thursday, March 12, 2009 7:14 AM
To: Ted Lemon
Cc: [email-masked] WG
Subject: Re: [dhcwg] DHCPv6 router option

- Ralph

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Mar 2009 08:47:42 -0700

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Thursday, March 12, 2009 7:08 AM
> To: Ralph Droms (rdroms); Ted Lemon
> Cc: [email-masked]

One thing I haven't seen mentioned yet (or maybe I missed
it) is SEND. For example, it may be useful for a router
to use SEND for RAs in order to represent that it is
indeed authorized to act as a router even if the RAs
contain no PIOs nor router lifetime. It might also be
necessary for RAs to contain other information such as
RIOs (RFC4191) that may not be practically available
from DHCP.

Unless there is a DHCP equivalent for conveying such
"other" information (is there?), I guess that in some
use cases that would argue for option 3 (use both)?

Fred
[email-masked]

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 13 Mar 2009 09:24:13 +0000

> signaling the host to ignore all future RAs

        Not forgetting "DHCP guard" ...

        /Niall

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 11 Mar 2009 14:13:06 -0400

P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Iljitsch
> van Beijnum

That's not a problem I'm experiencing.  YMMV.

> opposition if that is what you intend to standardize here.

You are welcome to use RAs; that standard exists.  I want to be able to
provide information via DHCP.

> of the network if the DHCP server dies or someone fatfingers its
config.

The draft says "option," right?  Section 5.1: the client has to request
the 
Default Router options.  One predictable solution is to have the client
request a default router from DHCP if not learned through RA.  I
haven't worked through the timing there; possible race condition or
delay in configuration.

I see a data normalization issue with providing interdependent 
information from two authoritative sources.
I generally find broadcast capabilities announcements unsatisfactory, 
both because they are chatty, and because they facilitate
reconnaissance.
A resource request ("Configure me") is less chatty, and though more
subject to a race response attack, that's essentially an authentication
issue, and not made harder or easier by adding this option.

Lee

This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 13 Mar 2009 09:50:45 -0700

> benefit to just declare this as "out-of-scope". Perhaps it can be

I would like to amplify this with a little bit more specific ideas for
progress.

Make no attempt to address the issue in this draft, outside of a very
generic description of what the parameter contents are used for.

Whoever is actually interested in the perpetual circular discussion of
which configuration parameter should take precedence over others,
because obviously there is a one-size-fits-all answer for that
(sarcasm), take that to v6ops, and write any drafts there, citing this
draft's RFC # along with any other sources of configuration.

This cleanly segregates the /software/ requirements (DHC scope) from
the /operational/ requirements (v6ops scope), and it would permit
folks like me to say our software conforms with this RFC specification
without having to ensure it is only installed in complying operating
systems, and used in complying networks.

In essence, it makes neighbor discovery an informative reference, not
a normative reference, so that the stated requirement (to run DHCPv6
in an environment with no RAs) can be accomplished without unused
software.

> this work until that document is also available.

Provided we elide the operations discussion for v6ops to solve (or
not, as the case may be), I see no reason to delay this work.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 13 Mar 2009 10:01:21 -0700

> use cases that would argue for option 3 (use both)?

There's a small blurb in Ralph's draft that says something like this,
"It does not matter if DHCPv6 is just as bad as DHCPv4, it can not be
worse."  And operation without RA is also a stated requirement.

So I think the answer is that we will be seeing a static routes option
in the very near future, and maybe it is not a bad idea to add it to
the current draft?

If we did have a static routes option, would we want that to cover any
default route(s) as well?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 Mar 2009 13:09:59 -0400

David - let me ask for specifics here.  What sections would you drop  
from the current draft, which would be replaced at a later date by  
additional RFCs from v6ops?

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 13 Mar 2009 12:14:49 -0700

On Fri, Mar 13, 2009 at 01:09:59PM -0400, Ralph Droms wrote:
> David - let me ask for specifics here.  What sections would you drop from 
> the current draft, which would be replaced at a later date by additional 
> RFCs from v6ops?

I don't think I would require the current draft to be changed
materially.  Section 4 contains no normative language, and is
therefore largely informational.  If it were mine, I would have
focused more on an overview of how the information gets from the
server to the client (ORO, placement of the option in the reply
packet (root? IA?)), with an admission at the end of its intended
use.

So my ideal section 4 wouldn't refer to RFC 4861 at all; except that I
understand its current use as a vehicle to explain the fields'
contents and possible use to likely readers (the author's intended
audience).  To those ends, I think the authors should have freedom
here.

And of course, I think you need to move the RFC 4861 reference to
an Informative References section, since I do not believe there has
been any normative language referring to ND currently, and I would
suggest against adding any.

So long as we're talking about me;

I have also been thinking that I would drop the router lifetime
values, preferring instead for the fields contents to be "valid
as long as the client holds its current lease (basically the longest
valid lifetime of any addresses granted)", but I don't know if
this interferes with some intention to support these options via
Information-Request messages, so I have been witholding comment.  I
planned to wait and see the presentation before suggesting
alterations.

I do know that our software, as it operates at userspace and not in
kernel space, does not seem to have reliable mechanisms to store
router lifetimes to the kernel (depends on architecture, on some it
is merely undocumented), and we probably would on some platforms tie
the insertion and removal of any routes to IP address lifetimes
instead until such time as kernel keepers make this configuration
possible.

I would prefer not to have to add extra complexity to track the router
lifetime separately, at any rate.

The idea is that this follows the same way we use or invalidate other
configuration state in the lease - such as nameservers or domain
search.  They are valid until the last address expires, and they are
updated (old-removed, new-inserted) upon every Renew or Rebind.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 13 Mar 2009 12:19:07 -0700

At Wed, 11 Mar 2009 15:05:33 -0400,

> they've already implemented for v4.

This issue has been well discussed (though I'm not sure if we reached
a clear consensus).  See draft-chown-v6ops-rogue-ra-03.txt and the
past discussions on that draft at v6ops.  I'm personally not yet
convinced that this 'rogue RA' issue warrants the introduction of a
new router option for DHCPv6 (despite its clear disadvantage such as
conflicting information), but I also understand mileage varies very
much on this issue.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Mar 2009 17:20:48 -0400

>in the very near future, and maybe it is not a bad idea to add it to

We already have ... there is:
http://www.ietf.org/internet-drafts/draft-dec-dhcpv6-route-option-01.txt

   This document describes the DHCPv6 Route Option for provisioning
   static IPv6 routes by a DHCPv6 client.  It is primarily envisaged for
   implementation on a DHCP client stack of a broadband Residential
   Gateway (RG) node.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David W. Hankins
Sent: Friday, March 13, 2009 1:01 PM
To: DHC WG
Subject: Re: [dhcwg] DHCPv6 router option

---

From: Ralph Droms <[email-masked]>
Date: Sat, 14 Mar 2009 18:55:20 -0400

What extensions would the default router option need to carry static  
routes as well?

Would there be some advantage to including timers of some sort on the  
static routes?

- Ralph

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Mar 2009 18:22:58 +0100

David W. Hankins wrote:
[...]
> planned to wait and see the presentation before suggesting

Not sure which is best, but for Information-Request you could also
consider the Information Refresh Time Option (RFC 4242).

Stig

> updated (old-removed, new-inserted) upon every Renew or Rebind.

Right, I thought you would add/update/remove routes just like other
information like nameserver info where you have no notion of lifetime
external to the DHCP client.

I think using DHCP for default router config is mostly useful where
you have a fixed address for the default router. Router failover can
be done using VRRP, HSRP or whatever (just like many people do for IPv4
today) without changing the router address. In that case you don't
really care much about lifetimes.

Stig

> 
> 
> ------------------------------------------------------------------------
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Mar 2009 14:01:31 -0400

> reasonable expectation that they are, in fact, working routers.

When ND was designed, it was felt that even routers that advertised
themselves could not be trusted. I.e., they might well say they are a
default router, but then blackhole packets sent to them. Hence, ND
includes Neighbor Unreachability Detection. And the notion of a
Default Router List.

All the RA does, is place a router on the client's Default Router
List. When the client needs a router, it selects one from the list. If
it turns out that the chosen router doesn't actually work, NUD takes
over and a new (different) router is selected. That is how you get
better robustness with IPv6 and routers.

The DHCPv6 option that we are proposing does nothing more than add a
router to the client's Default Router List. If that router doesn't
actually work, it is intended that client will behave just like above
and select another router. Thus, if the client has at least one
working router, it will use that one, regardless of how it learned of
it. It will not use routers that do not deliver packets.

Thus, I don't quite get the hysteria that this option is going to
"break" your network.

> which of the routers that advertise their presence a host should

As others of said, this would undermine a key operational requirement,
namely, the site doesn't want to use RAs at all.

> would normally make a host select a different default router.

It was 100% intended by the authors that NUD be done with DHC-learned
default routers just as with RA-learned default routers. We will make
that more clear in the next version.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Mar 2009 14:11:31 -0400

Bernie,

> server SHOULD NOT include these options in the response. This is what we

Right. This works today Just Fine.

> and only make use of the information provided via DHCP.

I disagree with this approach. The problem is that the
*implementation* is the one that has to decide whether to ignore RAs
or not. But that decision is really best made by the network
adminsistrator, since they know what is running on their network and
what their requirements are. The worst situation here would be if
clients did varying things, and the network admin couldn't run their
network as they'd like.

IMO, the only viable approach is that a client accept information from
both DHC and RAs and merge the info together. Clients are not smart
enough to know how to make any other choice when there are conflicts.

> 3. Use both? Perhaps 'prefer' the information provided via DHCP, perhaps

I would be nervous about configuration learned via one or the other as
being more "prefered". But I agree we need to think about this a bit
and have recommendations on what a client should implement.

> this work until that document is also available.

I agree that the draft needs to address this.

Thomas

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 20 Mar 2009 14:39:00 -0400

>I disagree with this approach. The problem is that the
 
The reason this approach may be desirable is that it avoids the rogue RA
issue.

There are flaws with this because if the client doesn't know in advance,
it will depend on what the client does and finds when it starts. If the
rogue RA arrives just as the client is starting up, the client may
accept that information and use it (potentially never doing DHCP). On
switched networks, this might be solved by having the switches filter
out (all) RAs.

My reason for including this was to address the following in section 3
(Requirments and Design Considerations):

   o  Misconfigured Router Advertisements immediately cause connectivity
      disruptions and can come from any router as a side effect of other
      changes in configuration or even simple attachment to a link.
      DHCP service is typically provided by a centralized service
      composed of fewer managed components, so DHCP server
      misconfiguration is less likely than delivery of misconfigured
      Router Advertisements.

If you allow RAs to be used, you haven't solve this problem? And how
would the draft address this requirement/design consideration?

Later in section 6, it does state:

So, why have the above mentioned bullet in 3 if this is clearly out of
scope? Or, perhaps you need to clarify how that issue is addressed by
the draft?

Perhaps it can also extend to the following bullet in section 3:

   o  Use of Router Advertisements provides identical configuration of
      default routers and prefixes for all hosts on a link, while some
      deployments require that different classes or groups of hosts be
      configured with different default routers and prefixes.

You could have cases where some clients use the RA data and others
explicitly do NOT use it (as they've been configured via DHCP).

I was assuming that if this was desirable, there would be an option (or
data in an option) to communicate to the client "don't use RAs; only use
DHCP data." One could take this a step further and have several
settings:
- Default Router settings:
	- Use RAs for default routers.
	- Use DHCP only for default routers.
	- Prefer DHCP default routers.
	- Prefer RA default routers.
- Prefix Information settings:
	- Use RAs for prefixes.
	- Use DHCP only for prefixes.
	- Prefer DHCP prefixes.
	- Prefer RA prefixes.

Note that today we have "prefer RA default routers" + "prefer RA
prefixes" (and DHCP can't supply either). One could add additional
settings to include SeND vs non-SeND Ras?

I think without something like this, the benefit of using DHCP for RA
related data is mostly lost (except perhaps providing additional prefix
advertisements).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Narten
Sent: Friday, March 20, 2009 2:12 PM
To: Bernie Volz (volz)
Cc: [email-masked]; Ted Lemon; Ralph Droms (rdroms)
Subject: Re: [dhcwg] DHCPv6 router option

Bernie,

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 19:18:02 -0400

Ralph,

Besides Alain Durand who has been asking for this potentially broken
idea to add a router option in DHCPv6, who else is a SP who asked for
this work? Alain also does not represent other cable vendors like
Time-Warner, or Cablevision etc.  For that matter, Alain himself says "I
don't even represent Comcast", so who else from Comcast can speak up and
say this work is needed? 

Let me also bring folks up to speed on Cable IPv6 standards from the
CableLabs.  We finished our Cable IPv6 standards more than three years
back and consumer devices like cable modems already follow the RA model
to get default rtr info and use DHCPv6 as well for ipv6 address
acquisition and other parameters like DNS etc.  A consumer device like a
cable modem has a huge inertia to changing any feature.   Likewise a
CMTS router that terminates the cable modems, being a Service Provide
box, has its own inertia to changing core features.  I spent two years
of my life between 2005=2007 nursing cable modem vendors to fix very
simple and core IPv6 bugs in their chips and I do consider this draft to
be rocking that boat.  The Provisioning system also changes. Then I and
Wes spent time finding show stopper bugs in hosts behind cable modems
and discovered that most operating systems were broken in some core data
forwarding behavior for IPv6 for a specific RA.  I do not like any IPv6
boat rocked even an iota unless there is compelling justification.

So let's not go backward.  Alain and Ralph, please explain what is the
problem in the cable broadband network that this draft is needed?
Please be super specific as to what the problem is.  Sorry, if the good
reasons have been given to the mailer - I have not caught up to mails on
this thread yet.  One year back when we discussed this issue with Alain,
I didn't hear any compelling reason.  What has changed since then?

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 19:49:57 -0400

All I am asking for is justification from cable operators because it seems one of them has fostered this idea.  It's not clear yet that the cable SP is saving money nor clear that all cable SPs would agree to making changes to cable IPv6 standards to accommodate such new work.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 23, 2009 7:38 PM
To: Hemant Singh (shemant); Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]; Ralph Droms (rdroms)
Subject: AW: [dhcwg] DHCPv6 router option

Hi Hemant,

it's not necessary to dive into the tons of emails that have been written about this in between. 
You've seen the presentation by Thomas and he clearly stated that some ISPs want to operate their networks in that way in order to  safe the money they have already invested in their networks and provisioning systems.

I can not say that I like this approach very much from an architectural point of view, but from an ISP perspective its the easiest and cheapest way to implement IPv6 without major re-structuring of products / processes and major costs.

So give the ISP the choice to chose which approach it implements and what it has to pay for offering IPv6 to its customers.

Only my 2 cent 
	Olaf (working for an ISP)

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hemant Singh (shemant)
Gesendet: Dienstag, 24. März 2009 00:18
An: Bernie Volz (volz); Thomas Narten
Cc: [email-masked]; Ted Lemon; Ralph Droms (rdroms)
Betreff: Re: [dhcwg] DHCPv6 router option

Ralph,

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 19:59:09 -0400

Ralph,

You see one obvious problem here?  With only ND and RA we have a RA
guard solution to deal with for rouge RAs or misconfigured RAs.  With
DHCPv6 option now we have to think of two solutions for most such
problems in an IPv6 network.  Interesting use of our times....

Hemant

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 00:38:01 +0100

Hi Hemant,

Only my 2 cent 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hemant Singh (shemant)
Gesendet: Dienstag, 24. März 2009 00:18
An: Bernie Volz (volz); Thomas Narten
Cc: [email-masked]; Ted Lemon; Ralph Droms (rdroms)
Betreff: Re: [dhcwg] DHCPv6 router option

Ralph,

Thanks,

Hemant

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 00:59:54 +0100

INHO it's not a cable operator kind of questions. AFAIK also DSL providers are asking for such kind of solution. And it may be that the SP does not safe money with it's concrete network implementation but he can definitely re-use the biggest part of its provisioning and business supporting systems.

Olaf

-----Ursprüngliche Nachricht-----
Von: Hemant Singh (shemant) [mailto:[email-masked]] 
Gesendet: Dienstag, 24. März 2009 00:50
An: Bonneß, Olaf; Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]; Ralph Droms (rdroms)
Betreff: RE: [dhcwg] DHCPv6 router option

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 23, 2009 7:38 PM
To: Hemant Singh (shemant); Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]; Ralph Droms (rdroms)
Subject: AW: [dhcwg] DHCPv6 router option

Hi Hemant,

Only my 2 cent 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hemant Singh (shemant)
Gesendet: Dienstag, 24. März 2009 00:18
An: Bernie Volz (volz); Thomas Narten
Cc: [email-masked]; Ted Lemon; Ralph Droms (rdroms)
Betreff: Re: [dhcwg] DHCPv6 router option

Ralph,

Thanks,

Hemant

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Mar 2009 17:08:42 -0700

I'm moving this conversation to the int-area mailing list as it is of  
interest to the Internet Area as a whole, not just the dhc WG.   
Previous correspondents are bcc'ed...

- Ralph

On Mar 23, 2009, at 4:59 PM 3/23/09, <[email-masked]> wrote:

> INHO it's not a cable operator kind of questions. AFAIK also DSL  
> providers are asking for such kind of solution. And it may be that  
> the SP does not safe money with it's concrete network implementation  
> but he can definitely re-use the biggest part of its provisioning  
> and business supporting systems.
>
> Olaf
>
> All I am asking for is justification from cable operators because it  
> seems one of them has fostered this idea.  It's not clear yet that  
> the cable SP is saving money nor clear that all cable SPs would  
> agree to making changes to cable IPv6 standards to accommodate such  
> new work.
>
> Hemant
>
> You've seen the presentation by Thomas and he clearly stated that  
> some ISPs want to operate their networks in that way in order to   
> safe the money they have already invested in their networks and  
> provisioning systems.
>
> I can not say that I like this approach very much from an  
> architectural point of view, but from an ISP perspective its the  
> easiest and cheapest way to implement IPv6 without major re- 
> structuring of products / processes and major costs.
>
> So give the ISP the choice to chose which approach it implements and  
> what it has to pay for offering IPv6 to its customers.
>
> Only my 2 cent

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:18:05 -0700

Hemant,

I am certain I am qualified to reply here given my role leading Comcast's
IPv6 deployment.  The deployment of IPv6 in cable can proceed without a
default router option, I mentioned this in the INT area meeting and I will
repeat it here now.

I cannot speak for other MSOs.  I will likely investigate this further and
encourage others to speak up as needed.

I like yourself have spent an extraordinary amount of time over the past
several years ensuring that cable IPv6 implementations are deployable.  This
work has ranged from work on cable modems to CMTSs and provisioning systems
and then some.

Finally, I will also state that I have no issue with the this option being
specified as long as it done with proper context and attention to detail.

John
=========================================
John Jason Brzozowski
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
=========================================

> From: Hemant Singh <[email-masked]>
> Date: Mon, 23 Mar 2009 19:18:02 -0400
> To: Bernie Volz <[email-masked]>, Thomas Narten <[email-masked]>
> Cc: dhc WG <[email-masked]>, Ted Lemon <[email-masked]>, Ralph Droms
> <[email-masked]>

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:24:37 -0700

Hemant,

Do you think there is a case where a rogue RA would occur in a DOCSIS
network?  I am not sure I am following where you are going here.

Are you saying the another mechanism will now be required because a default
router option will be sent via DHCPv6?  When a default router option is sent
via DHCPv6 this value is generally administratively configured, what form of
protection would be required?

John

> Date: Mon, 23 Mar 2009 19:59:09 -0400
> To: Ralph Droms <[email-masked]>, Ted Lemon <[email-masked]>
> Cc: dhc WG <[email-masked]>

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:26:53 -0700

I do not think anyone has suggested that cable standards be changed at this
time to accommodate this option.  I for one am not hearing or seeing this
point being made.

John

> Date: Mon, 23 Mar 2009 19:49:57 -0400
> To: <[email-masked]>, Bernie Volz <[email-masked]>, Thomas Narten
> <[email-masked]>
> All I am asking for is justification from cable operators because it seems one
> of them has fostered this idea.  It's not clear yet that the cable SP is
> saving money nor clear that all cable SPs would agree to making changes to
> cable IPv6 standards to accommodate such new work.
> 
> Hemant
> 
> You've seen the presentation by Thomas and he clearly stated that some ISPs
> want to operate their networks in that way in order to  safe the money they
> have already invested in their networks and provisioning systems.
> 
> I can not say that I like this approach very much from an architectural point
> of view, but from an ISP perspective its the easiest and cheapest way to
> implement IPv6 without major re-structuring of products / processes and major
> costs.
> 
> So give the ISP the choice to chose which approach it implements and what it
> has to pay for offering IPv6 to its customers.
> 
> Only my 2 cent

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 20:27:12 -0400

Olaf,

How large is your network in terms of number of subs? I don't know an ISP's job is easier one way or another till I know the size of your deployment and what do you deploy?  Broadband modems, or are you an ISP to commercial companies where the ISP Internet connection serves an Enterprise. What are the devices in your network for hosts?

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 23, 2009 7:38 PM
To: Hemant Singh (shemant); Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]; Ralph Droms (rdroms)
Subject: AW: [dhcwg] DHCPv6 router option

Hi Hemant,

Only my 2 cent 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hemant Singh (shemant)
Gesendet: Dienstag, 24. März 2009 00:18
An: Bernie Volz (volz); Thomas Narten
Cc: [email-masked]; Ted Lemon; Ralph Droms (rdroms)
Betreff: Re: [dhcwg] DHCPv6 router option

Ralph,

Thanks,

Hemant

---

From: Frank Sweetser <[email-masked]>
Date: Mon, 23 Mar 2009 20:27:21 -0400

> problems in an IPv6 network.  Interesting use of our times....

Leaving the router option out of DHCPv6 only means that you don't have to 
protect against a rogue/misconfigured router DHCP option.  Unfortunately, it 
doesn't get you off the hook for all of the other ways that DHCpv6 can be 
abused or misconfigured.

As a real world example, there is at least one family of viruses in the wild 
that uses a local DHCP server.  It maliciously reconfigures other hosts on the 
local subnet with a rogue DNS server, which in turn is used to trick web 
browsers into viewing pages loaded with exploits.

Crippling DHCPv6 by leaving out a router option may remove one way that DHCP 
can be used to break a network, but it doesn't eliminate the requirement the 
need for a v6 DHCP guard - without it there are still too many ways to play 
silly buggers with the local subnet.

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:28:29 -0700

I think it is important for us to clarify what types of broadband providers
are requesting this option.  Exactly who is not relevant at this time.
Perhaps there is an education that is required or there are genuine
challenges in some environments.

John

> From: <[email-masked]>
> Date: Mon, 23 Mar 2009 19:38:01 -0400
> To: Hemant Singh <[email-masked]>, Bernie Volz <[email-masked]>, Thomas
> Narten <[email-masked]>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 20:31:34 -0400

John,

Someone has already mentioned a "Rogue RA" situation.  Vista was
supposed to be a host but Vista began sending RA.  Why can't someone
hack Vista in a cable network behind a bridged IPv6 cable modem have
Vista send an RA sent to the CMTS? This is a rouge RA in the cable
DOCSIS network.

Hemant

-----Original Message-----
From: John Jason Brzozowski [mailto:[email-masked]] 
Sent: Monday, March 23, 2009 8:25 PM
To: Hemant Singh (shemant); Ralph Droms (rdroms); Ted Lemon
Cc: dhc WG; [email-masked]
Subject: Re: [dhcwg] DHCPv6 router option

Hemant,

Are you saying the another mechanism will now be required because a
default
router option will be sent via DHCPv6?  When a default router option is
sent
via DHCPv6 this value is generally administratively configured, what
form of
protection would be required?

John

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 20:33:08 -0400

I have a private email where it was mentioned to me that such an option may change the DOCSIS MULPI.  I'll be happy to unicast that email to you and the ADs.  That is why I am asking questions.

Hemant

-----Original Message-----
From: John Jason Brzozowski [mailto:[email-masked]] 
Sent: Monday, March 23, 2009 8:27 PM
To: Hemant Singh (shemant); [email-masked]; Bernie Volz (volz); Thomas Narten; [email-masked]
Cc: dhc WG; Ted Lemon; Ralph Droms (rdroms)
Subject: Re: [dhcwg] DHCPv6 router option

John

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:34:12 -0700

Like I said earlier we need to understand who or what type of provider is
making this request.  I am not aware of cable providers making this request,
I have not.

John

> Date: Mon, 23 Mar 2009 19:59:54 -0400
> INHO it's not a cable operator kind of questions. AFAIK also DSL providers are
> asking for such kind of solution. And it may be that the SP does not safe
> money with it's concrete network implementation but he can definitely re-use
> the biggest part of its provisioning and business supporting systems.
> 
> Olaf
>

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:38:36 -0700

Frank,

Are you suggesting we specify a way in DHC to prevent people from improperly
configuring their DHCPv6 servers?

John

> From: Frank Sweetser <[email-masked]>
> Date: Mon, 23 Mar 2009 20:27:21 -0400
> To: Hemant Singh <[email-masked]>

---

From: John Jason Brzozowski <[email-masked]>
Date: Mon, 23 Mar 2009 17:41:24 -0700

Router advertisements from a CPE behind a cable modem can be prevent using
various DOCSIS techniques.

John

> Date: Mon, 23 Mar 2009 20:31:34 -0400
> To: "Brzozowski, John" <[email-masked]>, Ralph Droms
> <[email-masked]>, Ted Lemon <[email-masked]>
> Cc: dhc WG <[email-masked]>, <[email-masked]>
> Subject: RE: [dhcwg] DHCPv6 router option
> 
> John,
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Mar 2009 17:48:05 -0700

Please respond only to the [email-masked] and leave off dhcwg on  
any responses.

- Ralph

On Mar 23, 2009, at 5:08 PM 3/23/09, Ralph Droms wrote:

> I'm moving this conversation to the int-area mailing list as it is  
> of interest to the Internet Area as a whole, not just the dhc WG.   
>> the SP does not safe money with it's concrete network  
>> implementation but he can definitely re-use the biggest part of its  
>> provisioning and business supporting systems.
>>
>> Olaf
>>
>> All I am asking for is justification from cable operators because  
>> it seems one of them has fostered this idea.  It's not clear yet  
>> that the cable SP is saving money nor clear that all cable SPs  
>> would agree to making changes to cable IPv6 standards to  
>> accommodate such new work.
>>
>> Hemant
>>
>> So give the ISP the choice to chose which approach it implements  
>> and what it has to pay for offering IPv6 to its customers.
>>
>> Only my 2 cent

---

From: Frank Sweetser <[email-masked]>
Date: Mon, 23 Mar 2009 20:54:23 -0400

> configuring their DHCPv6 servers?

Not at all.  I run a network full of students, so I'm thoroughly aware of the 
futility of assuming that all of your clients are well behaved ones =)

My point simply was that, in any network full of untrusted hosts, there are 
multiple ways for a rogue DHCP server to cause network problems, regardless of 
the existence or lack of a router DHCPv6 option.  If you're at all concerned 
about rogue DHCPv6 servers, then you absolutely need some form of switch based 
"DHCP guard" - a filter applied to all edge ports which prevents them from 
sending out the rogue DHCP advertisements.

So in other words, with or without the DHCPv6 router option, you still have to 
spend the time on a DHCP guard or you're going to be vulnerable to rogue DHCP 
servers.

---

From: [email-masked]
Date: Tue, 24 Mar 2009 15:51:15 +0100 (CET)

> making this request.  I am not aware of cable providers making this request,

I work for a DSL provider. We would very much like to have a DHCPv6
router option. As mentioned this has been discussed extensively on 
the dhcwg list. Our reasons for wanting a DHCPv6 router option are
mainly:

- We would like to have *all* the dynamic configuration in one place,
specifically DHCP. DHCP hands out much more info than RA (RA alone
cannot do it).

- We already have an extensive DHCP based infrastructure, which ties
in with other operational support systems.

- We much prefer to have *one* mechanism to distribute information to
CPEs (has to do with support, debugging, documentation etc).

There is also the argument that some kind of "DHCPv6 guard" is needed
independently of whether a DHCPv6 router option exists or not.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 24 Mar 2009 12:58:42 -0400

While it is still early for me to tell exactly what the semantics around
these option(s) will be, I think there are other technologies (even
Cable) where this could be extremely beneficial.

The reason is that it could eliminate periodic RAs. And for
non-broadcast technologies (Cable, 3GPP, DSL, etc), that could be a big
win. The client can be given the router information with the DHCP
transaction and renewed when the lease is renewed.

For non-broadcast networks, having to send an RA to each "client" every
N seconds is costly (especially if you have thousands or millions of
devices connected). Consider also the fact that sometimes the device
connecting is doing so via Ethernet emulation, so it can't be told that
seeing RAs once is a blue moon is OK.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 24, 2009 10:51 AM
To: [email-masked]
Cc: [email-masked]; Hemant Singh (shemant); Bernie Volz (volz);
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Ralph Droms (rdroms)
Subject: Re: [dhcwg] DHCPv6 router option

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 24 Mar 2009 16:01:35 -0700

On Mon, Mar 23, 2009 at 07:18:02PM -0400, Hemant Singh (shemant) wrote:
> this work?

Speaking purely as a DHCPv6 software implementor, and an IPv6 operator
you would no doubt believe to be of very little significance, I can
say that Alain Durand is not the only operator who has requested this
DHCPv6 software feature.  It is quite a staggering number of operators
who would prefer to run their networks in this way (or rather, who
would prefer not to operate with RA), ranging from large to small.  I
can, but will not, name them.  I do not think they signed up either
for me to speak as their proxy, nor for them to be interrogated by
you.  They have day jobs.

I think it is interesting that someone (was it David Thaler?) said at
the microphone in INTAREA that "If it is the case that DHCPv6 must
have feature parity with DHCPv4, then these options do not complete
that requirement."  I thought this was very insightful, and wholly
true.

I have information that other drafts are forthcoming.  I think we are
going to see a wave of work due to these operators that wish for IPv6
to be an equal-penalty upgrade, and not "lose features" by it.  Said
another way, it does not matter if IPv6 sucks equally to IPv4 (from
their own personal point of view about how networks should be built),
or has no compelling feature outside of address space to justify
itself, it merely must not suck worse.

We are going to see more efforts to make IPv6 "suck the same."

> Alain and Ralph, please explain what is the
> Please be super specific as to what the problem is.

I believe this discussion is reasonably fully, and appropriately
provided in the draft's Introduction, and has been presented in full
during the int-area (and I presume shortly the rtg-area) meeting.  I
do not think we will gain anything through repetition of it.

> I didn't hear any compelling reason.  What has changed since then?

Nothing has changed.  You could say that the IETF's collective answer
that the customers' requirements are insufficient justification has
been rejected by the customers.  I see no reason why that will change
either.

On this issue, I will defer to the customers' requirements and reject
the collective's vision to change them.

You are free to make your own determination.

---

From: Danny Mayer <[email-masked]>
Date: Sun, 29 Mar 2009 13:32:00 -0400

Frank Sweetser wrote:
> Not at all.  I run a network full of students, so I'm thoroughly aware
> of the futility of assuming that all of your clients are well behaved
> ones =)
> 
> My point simply was that, in any network full of untrusted hosts, there
> are multiple ways for a rogue DHCP server to cause network problems,
> regardless of the existence or lack of a router DHCPv6 option.  If
> you're at all concerned about rogue DHCPv6 servers, then you absolutely
> need some form of switch based "DHCP guard" - a filter applied to all
> edge ports which prevents them from sending out the rogue DHCP
> advertisements.
> 
> So in other words, with or without the DHCPv6 router option, you still
> have to spend the time on a DHCP guard or you're going to be vulnerable
> to rogue DHCP servers.
> 

There's already a virus in the wild that is doing this. See
Trojan.Flush.M. In fact Googling for this shows that there is a new
version out:
http://arstechnica.com/security/news/2009/03/new-version-of-dns-server-trojan-flushm-spotted-in-the-pipe.ars

Though this is more about using DHCP guard everywhere.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 30 Mar 2009 13:23:21 -0700

> Though this is more about using DHCP guard everywhere.

This particular attack vector isn't new, but we are seeing a
recent 'resurgance' (which suggests to me that other more attractive
vectors are getting nailed down).

The problem of casual interconnections - where a client system has no
a priori knowledge about the network it is about to be connected to -
demands some kind of validation of network-offered configuration.  The
trouble then becomes, how do you validate configuration without using
it?

Even if you trust some off-site validation mechanism (e.g. certificate
chains), you need working network access to acheive it, which means
using the offered (bad) configuration.  The agent performing this
operation knows not to trust the configuration, but other applications
on the same system might not.

This suggests to me that a host operating system needs a "middle
ground" between the up-to-now boolean configuration state, so that
configuration state can be used provisionally - only to ratify the
configuration - and not by higher layer applications.

One potential candidate way forward is emerging in today's *nix
desktops, which have a 'NetworkManager' applet or similar.  This
applet could potentially be a place where the "we have config, but
do not use it yet" problem could be solved, provided that more (or
the most important) applications were integrated to listen.

The trouble of course is coming up with a model whereby a DHCP server
administrator can reasonably be proven to be 'in control' of a range
of IP(v*) addresses.