Subject: Re: [69ATTENDEES] DHCP

From: Gert Doering <[email-masked]>
Date: Tue, 11 Sep 2007 11:34:37 +0200

Hi,

On Tue, Jul 24, 2007 at 07:30:38PM +0100, Tim Chown wrote:
> Any comments on
> 
> http://www3.ietf.org/proceedings/07jul/slides/dhc-5.pdf
> 
> to the v6ops list would be welcome.   

Took a while - sorry.

 - good summary of the problem

 - the possible answers pretty much cover the solution space

 - the "recommended" (bold) answer ("enhance DHCPv6 to add default router 
   support") is a bit DHCP centric for my taste, but then, I'm part of
   the "RA should be sufficient, why use DHCP?" camp.

good starting point for discussion.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  122119

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 11 Sep 2007 11:48:09 +0200

"RA should be sufficient, why use DHCP?"

Maybe people like to have centrally managed solution?
I don't see how RA can be done centrally at this time?

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gert Doering
Sent: Tuesday, September 11, 2007 11:35 AM
To: [email-masked]
Subject: Re: [69ATTENDEES] DHCP

Hi,

Took a while - sorry.

 - the "recommended" (bold) answer ("enhance DHCPv6 to add default
router 
   support") is a bit DHCP centric for my taste, but then, I'm part of
   the "RA should be sufficient, why use DHCP?" camp.

Gert Doering
        -- NetMaster

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Sep 2007 11:59:29 +0200

Hi,

> I don't see how RA can be done centrally at this time?

If you say "centrally managed solution", does this mean stateful DHCP,
or stateless DHCP?

For the latter, I can't see much benefit over RA, except that some fields
in RA are still missing (DNS servers).

Whether or not a router vendor permits me to centrally manage the extra 
information in the RAs should not influence the discussion about the 
actual protocol - that's just a management software issue.

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Sep 2007 13:32:14 +0100

> good starting point for discussion.

The text was in bold as the talk was originally given to the DHC wg and
thus a (possible!) DHC 'solution' was highlighted.
 
I'll get the slides into a draft soon, I think the questions raised at
both v6ops and dhc are now avauilable in WG minutes so can incorporate
those into such a draft.

-- 
Tim

---

From: Doug Barton <[email-masked]>
Date: Tue, 11 Sep 2007 10:15:36 -0700 (PDT)

> in RA are still missing (DNS servers).

Or, "some fields are adequately supplied by DHCP and are therefore not 
necessary (or desirable) to add to RA," depending on your perspective. :)

Doug

-- 

 	If you're never wrong, you're not trying hard enough

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Sep 2007 21:30:14 +0200

Hi,

> necessary (or desirable) to add to RA," depending on your perspective. :)

I didn't want to re-open that discussion (just commented on the document
that comments were solicited for).  But the most important argument for
us is "RA is there anyway, why undergo the effort to set up yet another
service?".

I want to point out that we *are* an operator -- but we have a different
customer structure than large-scale DSL or cable operators, where a
centralized DHCP is well-established in IPv4 land.

Everbody's network varies, and we take some offense at attempts from 
folks to stuff DHCP down our throats.

Gert Doering
        -- NetMaster

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 12 Sep 2007 10:27:10 +0100

> us is "RA is there anyway, why undergo the effort to set up yet  

	[ snip ]

	Especially _just_ for finding the DNS.

> Everbody's network varies,

	[ Heck, our network varies, too! 8-) ]

	Seriously though, I would see it as an unfortunate mistake to take
	the view that the capabilities of RA and DHCP to provide configuration
	data should be strictly disjoint.  The important point here is the
	distinction between 'capability' and actual 'advertisement'.

	If DHCP is a 'natural' means to meet some service requirement, it may
	be convenient to have it provide configuration data which might
	otherwise be provided by RA.  Implementors should take care to
	provide configuration options for both, as they will be needed in
	order to allow netadmins the scope they need to exercise their options
	and avoid conflicting advertisements.

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 12 Sep 2007 15:13:04 +0200

My believe is that either 'DHCP' OR 'RA' provides this exclusively and
not by both.
What if a host receives from both an announcement? (we could create
policies etc... however 
policies just complicates these aspects.).

Would central services not be best announced by a central capable
technology?

G/  

-----Original Message-----
From: Niall O'Reilly [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 11:27 AM
To: Gert Doering
Cc: Niall O'Reilly; Doug Barton; Gunter Van de Velde (gvandeve);
[email-masked]

On 11 Sep 2007, at 20:30, Gert Doering wrote:

> I didn't want to re-open that discussion (just commented on the 
> document that comments were solicited for).  But the most important 
> argument for us is "RA is there anyway, why undergo the effort to set 
> up yet another service?".

	[ snip ]

	Seriously though, I would see it as an unfortunate mistake to
take
	the view that the capabilities of RA and DHCP to provide
configuration
	data should be strictly disjoint.  The important point here is
the
	distinction between 'capability' and actual 'advertisement'.

	If DHCP is a 'natural' means to meet some service requirement,
it may
	be convenient to have it provide configuration data which might
	otherwise be provided by RA.  Implementors should take care to
	provide configuration options for both, as they will be needed
in
	order to allow netadmins the scope they need to exercise their
options
	and avoid conflicting advertisements.

	Best regards,

	Niall O'Reilly

---

From: Gert Doering <[email-masked]>
Date: Wed, 12 Sep 2007 15:37:21 +0200

Hi,

> policies just complicates these aspects.).

Thus: "why run DHCP at all"...

> Would central services not be best announced by a central capable

There is nothing inherently more or less "central capable" in DHCP than
in RA.

Without DHCP relay, DHCP isn't very much "centralized" (and it's easily 
imaginable that folks run per-subnet DHCP servers, handing out different 
information) - and a central management solution could easily make RA 
"central capable", given router vendor support.

Just because *some* current IPv4 deployments favour DHCP doesn't mean that
it's the right approach for *all* future IPv6 deployments.

Gert Doering
        -- NetMaster

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 12 Sep 2007 23:22:15 +0100

> Thus: "why run DHCP at all"...

	Or conversely, and equally legitimately, why run RA at all?
	Not that I'm specifically advocating that position.  8-)

> [ ... ]

	This "some/all" distinction is the real point.

	I have a few reasons for needing DHCP today on our university's net:
	simple IPv4 autoconfiguration (of course), DNS discovery, and a few
	applications which need more exotic support ('next' and TFTP servers
	for Cisco phones;  special application options retrieved using
	DHCPINFORM).

	I don't see the third (exotic) category going away.  I don't say
	'unfortunately', because it's not worth moaning about life being
	always more complicated than it might be.  Besides, there's job
	continuity ... 8-)

	RA-only and DHCP-only houses there will surely be. They may be
	a majority; I just don't know.  Vendors and implementors will
	no doubt be happy to accommodate both of these, as they can offer
	a complete solution.  There will also be houses where neither of
	these quite meets the requirements (technical, layers 8 and above,
	or whatever).  These houses will need to profile their RA and DHCP
	services so that they "play nice" with each other.  They will look
	to vendors and implementors who will have taken care to allow
	different slices of either service to be disabled so that it can be
	offered only by the other service.

	One size just won't fit all.

	Stop me if I haven't noticed that this is all just a "violent  
agreement".

	Best regards,

	Niall O'Reilly

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Sep 2007 08:37:29 +0200

Hi,

> 	Stop me if I haven't noticed that this is all just a "violent  

Well, I fully agree with you.  "Networks differ, so do requirements".

I have some issues with some folks from the DHCP camp refusing to understand
that there are operators that just follow a different operational model.

Gert Doering
        -- NetMaster

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 15:46:31 +0900 (JST)

> that there are operators that just follow a different operational model.

	i agree that vendors would implement whatever they would need to, but
	iirc the group is here to give guidance for operations.

	the primary issue with DHCP-based address assignment is the requirement
	for DHCP server to keep state.  due to this, major DHCP server
	implementation suffers from reading in lease database when it reboots
	(stops for 5 minutes).  DHCP server is a single point of failure.

	with RA-based address autoconfiguration and DHCPv6-lite based stateless
	DNS server address passing, there's no need for keeping state in the
	server side, hence there's no single point of failure.

itojun

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Sep 2007 08:56:34 +0200

Hi,

> 	iirc the group is here to give guidance for operations.

... and to listen to operators, to avoid giving guidance that completely
misses the target.

> 	server side, hence there's no single point of failure.

We just don't want to run yet another service that could fail, needs 
configuration, and possibly debugging if client machines are unhappy.

Routers are there, so RAs are there anyway.  DHCP is an extra.

Gert Doering
        -- NetMaster

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Sep 2007 16:00:45 +0900 (JST)

oops, sent privately by mistake.

itojun

> 	just checking: so you are voting for adding DNS server address info
> 	into RAs?
> 
> 	i just do not want RA be a kitchen sink, so DHCPv6-lite is a good-
> 	enough compromise for me.  if you piggyback DNS server address info
> 	into RAs, you do need to configure the info into every routers you got.
> 
> itojun
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Sep 2007 09:17:21 +0200

Hi,

> 	just checking: so you are voting for adding DNS server address info

This would solve one part of our remaining issues with IPv6 auto-
configuration, yes.  (The other part is "rouge RAs", which is not
that easy).

> 	into RAs, you do need to configure the info into every routers you got.

Yep.

The alternative would be to have DHCPv6-lite servers *on the router*
(remember: extra machines need power, maintenance, and tend to break) - so
we'd need to configure this data on the routers anyway.

This is targeting SoHo networks - no dedicated servers, just client PCs
and a router.  In our environment, the router is normally manually
configured, so configuring more stuff on it would not be a problem.

In some scenarios, DHCP prefix delegation from a centralized management
server -> SoHo router, and from there RA / DHCPv6-lite -> clients would 
also imaginable, but that's a different deployment scenario.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Sep 2007 09:20:20 +0200

Hi,

Yep.

Gert Doering
        -- NetMaster

---

From: Shane Kerr <[email-masked]>
Date: Thu, 13 Sep 2007 11:07:40 +0200

Gert,

I should probably let this thread die, but I wanted to talk about this
point...

I agree with this. But I disagree with the following characterization:

> I have some issues with some folks from the DHCP camp refusing to
> understand that there are operators that just follow a different
> operational model.

I wasn't around in "the good old days when IPv6 was being designed",
but my understanding is that IPv6 designers wanted to add
"autoconfiguration" to the list of improvements over IPv4. (This is a
bit silly, because everything other than "IPv6 has more addresses" has
been added to IPv4 - of course!) Because of this, they resisted
DHCPv6, and they continue to oppose DHCPv6.

I suppose I am "in the DHCP camp", but my take on it is not to oppose
network designs without DHCP, but rather that we should not attempt to
duplicate the functionality of DHCP in other protocols. So, you may
think "we can allocate addresses, all we have left is DNS
information!", but....

DHCP IS NOT JUST USED TO ASSIGN ADDRESSES!! It is a generic protocol
that hosts can use to find out information about the network that they
sit in. It also allows the DHCP server can update network
configuration (like reverse DNS, or firewall configuration, or routing
tables) based on host preferences.

So it may seem like DHCP folks are trying to impose one model of
networks. But the real goal is to avoid creating a second,
less-functional way of doing the same thing as DHCP already does in
the network.

We already have DNS information in router advertisements(*), so I
don't think it needs to be discussed any more. But expect to get
push-back from DHCP folks for whatever the *next* thing people try to
put into RAs is. Not because we are fighting against your network
design, but rather to avoid creating duplicate, complicated,
non-interacting protocols. We want to put the right functionality in
the right place.

(*) Okay, maybe only an experimental RFC:

http://tools.ietf.org/wg/dnsop/draft-jeong-dnsop-ipv6-dns-discovery-12.txt
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03819.html

--
Shane

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Sep 2007 11:53:41 +0100

> Would central services not be best announced by a central capable

As we discussed when considering DHCPv4 and DHCPv6 responses in a dual-stack
network, there is an assumption that responses are administratively set
to be consistent.   But there are appraoches to handle possible variances,
as per RFC 4477.

Many of those arguments could be made for RAs and DHCPv6.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Sep 2007 07:24:20 -0400

"The alternative would be to have DHCPv6-lite servers *on the  
router*" is decidedly *not* a hypothetical suggestion.  Cisco routers  
have DHCPv6-lite servers today.  Therefore, the fundamental step in  
configuration is, in the abstract, "hand out this address to hosts  
for DNS service".  Whether that configuration step alters the RA  
configuration or the DHCP configuration, and whether the address is  
distributed by ND or by DHCP is immaterial to the admin.

Restating what was said earlier in this thread: DHCPv6 is *not* just  
for assigning addresses and does *not* require a deployment model  
with a single DHCP server for the organization...

- Ralph

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Sep 2007 13:25:46 +0200

On Sep 13, 2007, at 11:07 , Shane Kerr wrote:

> "autoconfiguration" to the list of improvements over IPv4.

Right.

> (This is a
> been added to IPv4 - of course!)

Why is this silly? And _stateless_ autoconfiguration with stable  
addresses can't be added to IPv4 because the address space isn't  
large enough.

> Because of this, they resisted

Hm, how exactly did the IPv6 designers in ~ 1995 resist DHCPv6 that  
wasn't published until 2003?

> duplicate the functionality of DHCP in other protocols.

So we're free to NOT use DHCP as long as we forego the functionality  
that DHCP provides? I'm sorry, that's not a reasonable position.

> less-functional way of doing the same thing as DHCP already does in

Less-functional is in the eye of the beholder. I don't want to run  
DHCPv6 just to learn DNS server addresses. I can think of scenarios  
where DHCPv6 would be appropriate, but none of them apply to me today  
so I don't want to run the protocol. It's as simple as that.

> expect to get

In database design it's a bad idea to duplicate information. However,  
in database DEPLOYMENT this is pretty common for performance/ 
reliability reasons. Duplication can make sense.

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Sep 2007 13:37:12 +0200

Hi,

> distributed by ND or by DHCP is immaterial to the admin.

It might be immaterial to the *router* admin, but it certainly isn't
immaterial to the *client* admin.  If the client has no DHCPv6 on it,
and the relevant information isn't in ND/RA, this is pretty relevant.

As of today, most IPv6 capable client machines do *not* have DHCPv6 
clients (but adittedly, wouldn't know how to handle RA-with-DNS either).

Gert Doering
        -- NetMaster

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Sep 2007 07:54:47 -0400

RA+DHCPv6-lite works with Vista.

Which is pretty much the 800 pound gorilla in this scenario, and  
which, as you point out, is one more client than works with RA+DNS.

- Ralph

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Sep 2007 12:56:49 +0100

> wasn't published until 2003?

The publication of DHCPv6 was a long road, which started in 1995:

http://www.watersprings.org/pub/id/draft-ietf-dhc-dhcpv6-00.txt
Dynamic Host Configuration Protocol for IPv6
February 1995

The Dec 1994 IETF DHC meeting has apparently the first mention of DHCP 
requirement for IPv6:

ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/int/dhc/dhc-minutes-94dec.txt
(see under IPv6 Issues)

"Regardless of how addresses are managed, IPv6 will need some other
mechanism(s) to obtain other configuration parameters.  Some members of
the IPv6 design team claim there will be no other parameters."

But to call this opposition on that evidence would be a bit strong.

-- 
Tim

---

From: Shane Kerr <[email-masked]>
Date: Thu, 13 Sep 2007 14:11:54 +0200

On Thu, Sep 13, 2007 at 01:25:46PM +0200, Iljitsch van Beijnum wrote:
> 
> >(This is a bit silly, because everything other than "IPv6 has more
> >addresses" has been added to IPv4 - of course!)
> 

Yet Microsoft and Apple both do IPv4 autoconfiguration. Not perfect,
but it works.

I was mostly referring to the laundry-list of "features" from IPv6
that also exist in IPv4: multiple addresses per interface, IPSEC,
QoS, and so on.

> >Because of this, they resisted DHCPv6, and they continue to oppose
> >DHCPv6.
> 

The first DHCPv6 draft was published in February 1995, and the
resistance kept it from being published for 8 years. There were *28*
drafts before it was finally moved to RFC status!

http://www3.tools.ietf.org/html/draft-ietf-dhc-dhcpv6-00

> >I suppose I am "in the DHCP camp", but my take on it is not to
> >oppose network designs without DHCP, but rather that we should not
> >attempt to duplicate the functionality of DHCP in other protocols.
> 

Hey, it's your network, do what you want. If you want to configure
manually, go ahead. If you want to use a home-grown protocol, go
ahead. But if you want an IETF-approved way to do it, then you must
play nice with the IETF.

The opposition to duplicating DHCP functionality in other mechanisms
is the same as if you proposed an alternative to *any* existing
protocol. You should explain why the benefits your new protocol brings
cannot simply be added to the existing technology.

--
Shane

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Sep 2007 08:02:09 +1200

> Routers are there, so RAs are there anyway.  DHCP is an extra.

As far as I can see, in a minimal ("dentist's office") scenario,
the one thing a host must have in addition to addressing and
routing info is DNS servers. Since auto-configuration was
explicitly designed to support the minimal scenario, it seems
entirely rational to add DNS server info to RA. On the other hand,
DHCP can support dozens of additional features, and we surely
shouldn't import that level of complexity into RA.

      Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Sep 2007 23:52:34 +0200

> Yet Microsoft and Apple both do IPv4 autoconfiguration. Not perfect,

If you mean "you get a different address each time" and "only works  
in the absense of connectivity", then, sure. But lots of things work  
much better if connectivity to the internet at large is not a  
requirement.

> drafts before it was finally moved to RFC status!

Hm, I didn't know that.

And they still didn't get the stateful/stateless thing right (= the  
client must decide which type to use even though the server is in a  
better position to know what's appropriate).

So many cycles is never a good thing.

>>> attempt to duplicate the functionality of DHCP in other protocols.

By that logic, we should all be running RIP because OSPF is a  
duplication of functionality.

> ahead. But if you want an IETF-approved way to do it, then you must

The IETF is not in the business of telling people how to run their  
networks. And, fortunately, the IETF is not the same as the dhc wg.

> cannot simply be added to the existing technology.

Your assumption is that it's reasonable for me to implement DHCPv6 in  
my network to address a given need. That assumption is incorrect.

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Sep 2007 07:26:46 +0930

On Fri, 14 Sep 2007 08:02:09 +1200

> >> 	iirc the group is here to give guidance for operations.
<snip>
> shouldn't import that level of complexity into RA.

That sounds reasonable to me.

Would the following be a fair summary of the scenarios being talked
around?

1. No RAs, link local only addressing, Zeroconf techniques/Multicast DNS

2. RAs, ll + RA announced prefixes, RA announced DNS server(s)

3. RAs, ll + RA announced prefixes, RA announced DNS server(s), DHCP
for any other node configuration options

4. RAs, ll + RA announced prefixes, DHCP announced DNS server(s) + other node
configuration options.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Thu, 13 Sep 2007 16:00:42 -0700

> 4. RAs, ll + RA announced prefixes, DHCP announced DNS server(s) +  

I think scenario 3 is bad.  I see no good reason for RA with both O=1  
and DNS server options.  I'd be perfectly okay with requirement  
language that says DNS server options in RA must be not be sent, and  
must be ignored if received, when O=1.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Gert Doering <[email-masked]>
Date: Fri, 14 Sep 2007 08:53:37 +0200

Hi,

> 4. RAs, ll + RA announced prefixes, DHCP announced DNS server(s) + other node

Yes.  (Not taking stateful DHCPv6 into account, but if this is desired,
there are no alternatives anyway, except "manual configuration").

Gert Doering
        -- NetMaster

---

From: "Alvaro Vives Martinez" <[email-masked]>
Date: Fri, 14 Sep 2007 09:00:52 +0200

I would add to the list:

5. RAs, ll + DHCP announced prefixes + DHCP announced DNS server(s) + other
 node configuration options.

Regards,
Alvaro

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre
> de Mark Smith
> Enviado el: jueves, 13 de septiembre de 2007 23:57
> Para: Brian E Carpenter
> CC: Gert Doering; Jun-ichiro itojun Hagino; [email-masked]
> Asunto: Re: [69ATTENDEES] DHCP
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Sep 2007 22:40:24 +0930

On Fri, 14 Sep 2007 09:00:52 +0200

>  node configuration options.

I'm guessing that the RA in this scenario is only for default router announcement?

Regards,
Mark.

---

From: Kevin Loch <[email-masked]>
Date: Fri, 14 Sep 2007 10:21:25 -0400

> there are no alternatives anyway, except "manual configuration").

Don't underestimate the significance of full manual configuration or
DHCP with RA turned off.  Both of these modes will see significant
use.

You could also consider learning gateways from vrrp announcements.

- Kevin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Sep 2007 19:04:51 +0200

On 14-sep-2007, at 16:21, Kevin Loch wrote:

> Don't underestimate the significance of full manual configuration

++

When I first started doing stuff with IPv6 I didn't trust stateless  
autoconf so I used manual configuration. That's no longer an issue,  
but there are reasons why manual can be the best way to go. For  
instance, if you have a bunch of addresses sitting behind a router,  
you can either do manual and a single static route or you have to  
mess with routing protocols.

> or DHCP with RA turned off

DHCPv6 without manual configuration or RAs doesn't work because  
DHCPv6 can't tell you your default gateway.

(And there are other reasons why it's a bad idea.)

> You could also consider learning gateways from vrrp announcements.

Look at that, someone bothered to do work on VRRP for IPv6. That was  
a waste of time, because router advertisements and dead neighbor  
detection give you the same functionality without the need to  
configure stuff.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Sep 2007 12:03:09 -0700

Not having followed this discussion, IMHO there is
significant value in DHCPv6 prefix delegation. It can
be used to delegate recursively-nested site prefixes
and can even be used to delegate "fully-qualified"
prefixes (i.e., /128's). Not sure what any of this
has to do with IETF69 though...

Fred
[email-masked]

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 10:05 AM
> To: Kevin Loch
> Cc: [email-masked]

---

From: Kevin Loch <[email-masked]>
Date: Fri, 14 Sep 2007 15:06:49 -0400

Iljitsch van Beijnum wrote:
> DHCPv6 without manual configuration or RAs doesn't work because DHCPv6 
> can't tell you your default gateway.

That can be fixed (and I'm sure it will).

> Look at that, someone bothered to do work on VRRP for IPv6. That was a 
> waste of time, because router advertisements and dead neighbor detection 
> give you the same functionality without the need to configure stuff.

RA's are great in certain situations, and I use it on some subnets but
we must have a full set of tools that work with RA turned off.
There are situations where I cannot have hosts (servers in particular)
autoconfigure addresses or gateways, even accidentally.

- Kevin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Sep 2007 23:00:55 +0200

> That can be fixed (and I'm sure it will).

"Fixed" in the sense of "work better than today" is not possible, in  
my opinion.

Having routers announce their presence makes sure all kinds of  
trouble that can easily occur with IPv4 isn't an issue with IPv6.

>> Look at that, someone bothered to do work on VRRP for IPv6. That  
>> was a waste of time, because router advertisements and dead  
>> neighbor detection give you the same functionality without the  
>> need to configure stuff.

> we must have a full set of tools that work with RA turned off.

Why?

> autoconfigure addresses or gateways, even accidentally.

Then they shouldn't listen to discovery protocols such as RA but also  
DHCP (and VRRP in the sense that you were suggesting although VRRP  
isn't designed to be that).

I'm not sure what implementations will do when a statically  
configured default fails (succeeds?) dead neighbor detection...

---

From: "Ralph Droms \(rdroms\)" <[email-masked]>
Date: Fri, 14 Sep 2007 17:21:24 -0400

Sounds to me you're willing to force network admins to use RAs when they
don't really want to.

Which sound remarkably like what you object to when you think network
admins are being forced to use DHCP.

- Ralph

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Iljitsch van Beijnum
Sent: Friday, September 14, 2007 5:01 PM
To: Kevin Loch
Cc: [email-masked]
Subject: Re: [69ATTENDEES] DHCP

Why?

---

From: Kevin Loch <[email-masked]>
Date: Fri, 14 Sep 2007 18:08:23 -0400

Apologies to the list, this will be my last post on this subject.

>> we must have a full set of tools that work with RA turned off.

There are situations where hosts on the same segment need to use
different gateways.  There are many cases where self assigned
IPs (which might be used to source packets) are not desired.  Firewall
rules, accounting, VPN SA's and load balancers are just the tip of the
iceberg.  Convoluted topology due to mergers or migrations, customer
legacy designs or other odd requirements adds to the mess.  We have
tools in IPv4 to deal with this and the shotgun approach of RA would
not help here.

Even in cases where RA could be used, it is often desirable to use
manually selected non EUI-64 addresses which tend to be simpler.  This
also applies to ranges used by DHCP.  People still have to type and work
with IP addresses in IPv6.

>> There are situations where I cannot have hosts (servers 
>> in particular) autoconfigure addresses or gateways, even
>> accidentally.
 >
> DHCP (and VRRP in the sense that you were suggesting although VRRP isn't 
> designed to be that).

VRRP for failover of a statically configured gateway IP address is very 
useful.  I could use it today on my network if vendors supported it.

I can also see scenarios where VRRP + DHCP - RA could be useful in
mixed DHCP/static segments.  DHCP allows fine control over which
hosts are allowed to use it as well as which features are used.  You
don't always have administrative control over all hosts on a segment to
control behavior regarding RA's.

I'm not bashing RA completely.  It's a small efficient design and is
very convenient in certain situations. It just isn't appropriate for
every situation and many times will need to be turned off.  In those
cases we need other methods (like DHCP, VRRP).

- Kevin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Sep 2007 00:53:05 +0200

> admins are being forced to use DHCP.

We'll see when a draft appears that explains how to run an IPv6  
network without RAs.

And only a few messages back I mentioned that I sometimes use manual  
configuration in lieu of RAs...

---

From: "Alvaro Vives Martinez" <[email-masked]>
Date: Mon, 17 Sep 2007 09:55:13 +0200

> I'm guessing that the RA in this scenario is only for default router

Yes as of today specification. Also, as said before on this list, the RA
could include the flag bit that tells the host to use DHCPv6.

There is also another possible scenario, without RAs and just DHCPv6.

IMHO if there are people that are not deploying IPv6 because of the lack of
features of DHCPv6 or that they don't want to deploy RAs on their network,
we must try to know why (maybe an IPv4 minded point of view or the control
and flexibility DHCP offers, don't know) but for sure if the required
functionalities are added as required, IPv6 deployment will win. Lets's
think on this as a TRANSITION MECHANISM ;-)

Regards,
Alvaro

> > > > >> 	i agree that vendors would implement whatever they would
need
> to,
> > > but
> > > 4. RAs, ll + RA announced prefixes, DHCP announced DNS server(s) +
> other
> > > node
> > > configuration options.
> > >
> > > Regards,
> > > Mark.
> >
> >
> >
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> >
> >
> >
> >

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 20 Sep 2007 21:01:58 +0900

At Thu, 13 Sep 2007 14:11:54 +0200,

> http://www3.tools.ietf.org/html/draft-ietf-dhc-dhcpv6-00

This is probably an off-topic in this thread (or perhaps for this list
in the first place), but just out of curiosity...was the "opposition"
of the IPv6 designers the main reason that it took 8 years to complete
the DHCPv6 spec?  I didn't even know there was an opposition from the
"IPv6 designers" to defining the DHCPv6 protocol.  I recall there was
a discussion about whether to mandate implementing DHCPv6 on an IPv6
host (and as a result RFC4294 uses a MAY in section 4.5.5), but I
don't remember an argument that resisted defining the protocol.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Sep 2007 11:26:11 +1200

I was interested to notice this in draft-aboba-ip-config-02.txt:

> 3.3.  Fate Sharing
> 
>    If a server (or set of servers) is needed to get a set of
>    configuration parameters, "fate sharing" ([RFC1958] Section 2.3) is
>    preserved if the servers are ones without which the parameters could
>    not be used, even if they were obtained via other means.  The
>    possibility of incorrect information being configured is minimized if
>    there is only one machine which is authoritative for the information
>    (i.e., there is no need to keep multiple authoritative servers in
>    sync).  For example, learning default gateways via Router
>    Advertisements provides perfect fate sharing.  That is, gateway
>    addresses can be obtained if and only if they can actually be used.

  ...
>    ...Typically DHCP servers do not check for the
>    liveness of the configuration information they provide, or do not
>    discover new configuration information automatically.  As a result,
>    there is no guarantee that configuration information will be current.

     Brian

---

From: "Erik Kline" <[email-masked]>
Date: Thu, 20 Sep 2007 22:01:08 -0700

An argument for using the ll multicast addresses for "all dns
servers", and "all ntp servers", perhaps? Or/also SLP?

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Sep 2007 00:58:57 -0700

> servers", and "all ntp servers", perhaps? Or/also SLP?

Almost.  I see the architecture like this:

1) Use router solicitation to find your provisioned prefix and  
router, then stateless autoconfigure.

2) Discover ad-hoc services with multicast DNS service discovery (see  
<http://www.dns-sd.org/>)

3) Discover provisioned DNS resolving proxy servers with router  
advertisement options (see draft-jeong-dnsop-ipv6-dns-discovery).   
Failing that, use multicast DNS to discovery ad-hoc proxy resolving  
servers (query for _domain._udp.local SRV records).  Failing *that*,  
fall back completely to a local recursive resolver.

4) Discover the domains of local interest within the DNS horizon by  
querying for the DNS-SD signaling records in a reserved domain.

5) Discover all provisioned services in domains of local interest  
with non-multicast DNS-SD.

With an architecture like this, service discovery is fate-shared with  
the rest of the name resolution system.  Ad-hoc networks require zero  
configuration and no management.  The only possible appeal that DHCP  
has over this architecture, it seems to me, is that DHCP lets you  
keep on enjoying the opportunity to break your network-- by swapping  
ethernet cards around, which destroys the contrived mapping between  
MAC address and node identity you've been carefully managing at great  
expense and ever-expanding budgetary authority.

If IP networks were to be made brain-dead simple to operate, then  
Mahogany Row wouldn't be willing to pay such high salaries to the  
operators, now wouldn't they?

---

From: Shane Kerr <[email-masked]>
Date: Fri, 21 Sep 2007 11:22:29 +0200

> >   there is no guarantee that configuration information will be current.

So should we be advocating "perfect fate sharing" for all protocols?
It makes a certain amount of sense.

To do this, RA-style messages make a certain amount of sense. Of
course, you probably want to send these using UDP multicast in the
general case since most services are not really tied closely to the
network architecture. There may also be a need to provide different
information to the client, if the device implementing the protocol
acts differently depending on client information, so some sort of
client/server protocol might be helpful. Pretty soon you have have
DHCPv6... :)

As far as DHCP servers not discovering configuration information,
there is nothing preventing devices providing service from updating a
DHCP server with state information or a DHCP server checking it, if
this sort of "guarantee" is desirable. Or these devices can implement
tiny stateless-only DHCP servers on their own. I do not know if either
of these models has been pursed before in the IETF (I would not be
surprised, since it seems there are no new ideas in networking), but
maybe someone on this list knows?

--
Shane

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Sep 2007 17:04:21 +0200

On 21-sep-2007, at 1:26, Brian E Carpenter wrote:

>>  For example, learning default gateways via Router
>>    Advertisements provides perfect fate sharing.

I was saving this remark up for when we get to see the "do everything  
with DHCPv6" draft, but this is as good a time as any:

If we decide to go forward with putting gateway addresses in DHCPv6  
to gain administrative control over which gateway a host uses, in my  
opinion, the only way we can do this without the potential for  
serious harm is to make require that the same gateway address is both  
available in DHCPv6 and in RAs. So the DHCP information is more like  
selection mechanism between gateways in RAs than the authoritative  
source of the information itself.

And I agree with James' vision: having servers announce their service  
through a discovery mechanism is more robust than having an outside  
system enumerate them.

---

From: Doug Barton <[email-masked]>
Date: Fri, 21 Sep 2007 12:39:25 -0700 (PDT)

On Fri, 21 Sep 2007, Iljitsch van Beijnum wrote:

> I was saving this remark up for when we get to see the "do everything with 
> DHCPv6" draft, but this is as good a time as any:
>
> If we decide to go forward with putting gateway addresses in DHCPv6 to gain 
> administrative control over which gateway a host uses, in my opinion, the 
> only way we can do this without the potential for serious harm is to make 
> require that the same gateway address is both available in DHCPv6 and in RAs. 
> So the DHCP information is more like selection mechanism between gateways in 
> RAs than the authoritative source of the information itself.

Well at least you're finally making your argument explicit. You want RAs 
to be mandatory for everyone, but you don't want us to mandate the use of 
DHCP for you. Okey dokey.

> And I agree with James' vision: having servers announce their service through 
> a discovery mechanism is more robust than having an outside system enumerate 
> them.

This part I agree with. I think mDNS has a very bright future, and makes 
total sense in the "stateless autoconfiguration" case. "Well known 
addresses" is a path we should not go down.

Doug

--

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Sep 2007 22:20:11 +0200

On 21-sep-2007, at 21:39, Doug Barton wrote:

> Well at least you're finally making your argument explicit. You  
> want RAs to be mandatory for everyone, but you don't want us to  
> mandate the use of DHCP for you. Okey dokey.

Hey, I'm trying to show some openmindedness here by not rejecting the  
addition of gateway information to DHCPv6 out of hand. (Something  
which, apparently, the dhc wg didn't think was a good idea at the  
time DHCPv6 was conceived, because it isn't in there now.)

There are three questions:

1. Is there a reason why it would be helpful to run a network with  
routers but without RAs?

2. Would 1. be compelling enough to live with the loss of fate  
sharing it implies?

3. Would it be possible to set up hosts with default configuration  
that works both in currently deployed IPv6 networks and networks  
configured as per 1.?

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Sep 2007 13:38:33 -0700

On Sep 21, 2007, at 12:39, Doug Barton wrote:
>> And I agree with James' vision: having servers announce their  
>> service through a discovery mechanism is more robust than having  
>> an outside system enumerate them.
>
> This part I agree with. I think mDNS has a very bright future, and  
> makes total sense in the "stateless autoconfiguration" case. "Well  
> known addresses" is a path we should not go down.

I should note that multicast DNS-SD is the zero configuration variant  
of the more general-case usage of DNS service discovery.  I'm not  
making any argument against DHCP on the grounds that it fails to be a  
"zero configuration" protocol.  That's the whole point of DHCP: it's  
*SUPPOSED* to be not a zero configuration protocol.

My whole argument against DHCP is that it reinvents name resolution  
and service discovery, requiring effort to keep state data coherent  
between DNS and DHCP services, which is unnecessary since DNS alone  
is sufficient for meeting service discovery needs.

I can't imagine any reasonable usage scenario where the alternative  
is true, i.e. where DHCP is a required component of the  
infrastructure, but DNS can be disabled everywhere because it isn't  
needed.

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Sep 2007 13:50:27 -0700

> 2. Would 1. be compelling enough to live with the loss of fate  

This assumes that fate sharing is viewed by all participants as a  
feature, not a bug.  I'm not sure I should believe this is a valid  
assumption.

> that works both in currently deployed IPv6 networks and networks  

For some definition of "works"... remember, the next thing the DHCP  
people will want after they get default gateway and prefix length is  
to demand that DHCP servers can be authoritative for this  
information, not the routers, i.e. the DHCP servers will say to  
nodes, "turn off router solicitation and stop processing  
advertisements for the duration of your lease."

You might find that DNAv6 is required to kick nodes into giving up  
their DHCP lease and retrying router solicitation before they will  
"work" properly, i.e. just like with IPv4.

-- 
james woodyatt <[email-masked]>
communications software engineering
1 infinite loop; ms: 306-2TC; tel: x49423

---

From: "Alvaro Vives Martinez" <[email-masked]>
Date: Mon, 24 Sep 2007 09:29:49 +0200

> de Iljitsch van Beijnum
> Enviado el: viernes, 21 de septiembre de 2007 17:04
> Para: Brian E Carpenter
> CC: [email-masked]
> Asunto: Re: Architectural argument for RAs [Re: [69ATTENDEES] DHCP]
> 
> 

Following this line, would it make sense that the DHCPv6 server gets the
gateway(s) information from existing RAs? This would allow the host to
obtain "fresh" info and the host to fully be configured by means of DHCPv6
(this seems to be a need for some people).

Regards,
Alvaro Vives
Consulintel

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Sep 2007 08:23:43 +1200

> (this seems to be a need for some people).

That sounds right in principle, but what happens if the default gateway
is also acting as a DHCP relay, i.e. the DHCP server is on another subnet
and cannot see the local RAs?

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Sep 2007 11:38:59 -0700

Jinemi,

> don't remember an argument that resisted defining the protocol.

I think I can claim to be one of the "IPv6 designers".

My point of view on this is that there was never an opposition to  
DHCPv6 as described above.  DHCPv6 was always part of the IPv6 plan  
because we understood that there were going to be environments where  
it would be important.  For example large enterprises.  There was not  
any organized effort to delay DHCPv6.  As far as I understand the  
delay to move DHCPv6 forward was related to activities in the DHC  
w.g.  I have never been very active in the DHC w.g.

Where there is a disagreement is should DHCPv6 be the only way to  
deliver certain types of information to hosts.  For example the  
effort to try to standardize other mechanisms to deliver DNS  
recursive server information.  But this was not about being against  
DHCPv6.

I don't understand how this has been turned into the IPv6 designers  
delaying DHCPv6 for 8 years.  DHCPv6 is an important part of IPv6.

Bob