Subject: [dhcwg] RE: prefix length determination for DHCPv6

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 13 Aug 2007 13:25:42 -0400

DHCP server address would be useless because clients don't generally
unicast to the server/relay (and aren't allowed to unless the server has
sent a server-unicast option). And, if the server isn't on-link, unless
the client has an address of sufficient scope, it couldn't communicate
with the server directly.

And, what value does this add anyway?

If you are trying to get just get DNS server addresses, you can use
Information-Request (which is multicast) and you'll get the answer in a
Reply (which is unicast).

So, you add two messages - only one of which is multicast.

Even if you do use address assignment and thus Solicit, you can include
the Rapid Commit option which can save two messages (instead of
Solicit/Advertise/Request/Reply, you have Solicit/Reply). Only the
client's messages are multicast.

DHCPv6 messages are generally small and don't require a lot of back and
further. I really don't understand why people are objecting to one or
two request/reply exchanges (only the request of which is multicast).
Sure, it be nice if there were zero messages, but we're basically down
to as few as possible and most of these messages are tiny (especially
compared to the 300+ bytes that is the minimal size of DHCPv4 messages).

- Bernie 

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 1:06 PM
To: Leino, Tammy
Cc: Iljitsch van Beijnum; [email-masked]; John Jason Brzozowski (JJMB)
Subject: Re: prefix length determination for DHCPv6

Leino, Tammy wrote:
> Iljitsch, thank you for your comprehensive remarks.  I think my
> mistake was in believing an IPv6 router does not have to be
> configured to send RAs, but the DHCPv6 server could serve the same
> purpose as the RAs.  It appears DHCPv6 was meant to supplement RAs.
> 
> As an embedded developer, there is a lot of overhead in terms of code
>  space and memory requirements in the DHCPv6 protocol, particularly
> for customers wishing to just distribute DNS servers.  It would be
> nice if all the configuration options of DHCPv6 had been added to
> RAs.  This way, we would save on memory.

Errr... the RAs would become larger and bandwidth would be wasted
sometimes.

I'd rather extend the RA to include the DHCP Server address such that
the mobile does not need to discover the DHCP Server address, thus
gaining time by eliminating Solicit and Advertise DHCP messages.

But these things are relatively widely implemented and modifying
anything in the existing operation risks taking a lot of time...

Alex

> 
> Thank you again for your time and advice.
> 
> Best Regards, Tammy
> 
> 
> -----Original Message----- From: Iljitsch van Beijnum
> [mailto:[email-masked]] Sent: Monday, August 13, 2007 6:18 AM To:
> Leino, Tammy Cc: John Jason Brzozowski (JJMB); Hemant Singh
> (shemant); [email-masked] Subject: Re: prefix length determination for
> DHCPv6
> 
> 
> On 11-aug-2007, at 1:09, Leino, Tammy wrote:
> 
>> The reason I am not assuming there is a router on link configured
>> to send RAs with prefix options is because I don't see the point of
>>  DHCPv6 configuring addresses if a router is configured to do the
>> same job.
> 
> :-)
> 
>> Since the prefix length is carried in a prefix option of an RA, I
>> have to assume these will be absent on the link; otherwise, the
>> node would not be using DHCPv6 to obtain an address.
> 
> But then, why do you need addresses when you have no external 
> connectivity? A lot of stuff will work just fine over link local 
> addresses, although the need to include a scope identifier gets in 
> the way of some applications.
> 
>>>> (There is of course the consideration that at this time, very
>>>> few
>> IPv6 implementations can configure an address through DHCPv6.)
> 
>> Is this because of some shortcoming(s) in the specification or do 
>> network managers find DHCPv6 unnecessary?
> 
> First of all, the DHCPv6 specification was finished relatively late,
>  in 2003 if I'm not mistaken. Most major vendors had already 
> implemented IPv6 by then and I'm guessing that deployment levels so
>  far haven't exactly given them much reason to drastically update 
> their IPv6 implementations.
> 
> Then there is the confusion about stateful and stateless DHCPv6 and
>  the whole discussion about the meaning of the M and O bits in router
>  advertisements. I think this created uncertainty in the market place
>  for some time.
> 
> Since address configuration has always happened and continues to 
> happen through stateless autoconfiguration, DHCPv6 address assignment
>  wasn't implemented widely, and you can only use this mechanism when
>  you can be sure that both the server and the clients support it. It
>  looks like now that IPv6 is gaining more widespread attention that
>  more people want this because it's the same as in IPv4, but "old 
> school" IPv6 users are generally happy with stateless
> autoconfiguration.
> 
> That leaves:
> 
>> If they are not using DHCPv6, how do they distribute DNS servers
>> and other configuration information?
> 
> In practice? They don't. As long as you have IPv4, you can use IPv4
>  for this.
> 
> Other than that, you mostly manually configure an address. Although
>  DHCPv6 allows you to do this automatically, the trouble is that you
>  can't be sure that there will be a DHCPv6 server everywhere you go
> so in practice, the advantage of DHCPv6 over manual configuration is
>  limited. There was talk about using well-known anycasted addresses
>  for this but that never came off the ground.
> 
> In the near future we'll have draft-jeong-dnsop-ipv6-dns- 
> discovery-12.txt which is now in the RFC Editor queue. However, this
>  will have the same problem as DHCPv6: you can't be sure that someone
>  is making the info available until it's extremely widely
> implemented.
> 
>> I am interested in learning how well received DHCPv6 has been.  We
>>  have been slow to implement it in our OS because of low demand.
> 
> My opinion: DHCPv6 is a complex protocol that uses a relatively high
>  number of messages. In the past, UDP-based protocols have been 
> especially susceptible to security problems in their implementations.
>  As such, I'm very happy to do without it when I don't need it and I
>  feel stronly that DHCPv6 should NOT be initiated by clients by 
> default but only if RA flags indicate that they should do this, and
>  DNS configuration should be possible without DHCPv6.
> 
> Having said that, there can be situations where it's useful to assign
>  an address to an IPv6 host, so there is certainly a place for
> DHCPv6. And prefix delegation is brilliant, this is a great way to
> provision IPv6 CPEs with an address block.
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www1.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Aug 2007 20:26:47 +0200

> compared to the 300+ bytes that is the minimal size of DHCPv4  

It adds up if you have a large number of hosts on a subnet.

Which got me thinking: wouldn't it be great if a single message from  
a host could serve as both a router solicitation and a DHCP solicit  
message?

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Aug 2007 14:46:00 -0400

Following up on Bernie's comments about DHCPv6 for non-address  
configuration information, take a look at RFC 3736, "stateless DHCP  
Service for IPv6" (ftp://ftp.rfc-editor.org/in-notes/rfc3736.txt) for  
a summary of the minimal implementation and deployment needed for  
DHCPv6 as a complement to SLAAC.

And, as David points out, it's perfectly feasible to colocate a  
DHCPv6 server with a router.  IOS includes a DHCPv6 server, currently  
providing Information Request (RFC 3736) and Prefix Delegation (RFC  
3633) services.  I was involved with the implementation of the  
Information Request service; trust me, it's *quite* simple.

- Ralph

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Aug 2007 00:58:59 +0200

> Yes, as long as the router 'server' and the DHCP server get their  
> act together
> and present a single coherent reply to the host:-)

If they tell the host the same thing then obviously we don't need two  
protocols.

I don't think there is necessarily a problem with different sources  
telling a host different things. But what we need is some rules about  
how the host is supposed to react to this situation.

Also note that today, this is already reality: you can have multiple  
routers. Hopefully, they all broadcast the same prefixes (if they  
don't, you could use a prefix from router A over router B and run  
into filters, unfortunately, for unexplained reasons, OS makers seem  
to think this is appropriate behavior) but obviously they'll be  
advertising different default gateway addresses. There are no rules  
about which a host should pick, but we do have dead neighbor  
detection which makes sure that only working ones are used.

Back to my original point: a mobile host isn't going to know whether  
a network it connects to is using stateless autoconfig, DHCPv6 or  
both. Sending discovery messages for both is probably wasteful in  
most situations, and sending discovery messages for only one will  
lead to delays if it chose the wrong one. So having one discovery  
message that can lead to replies of both kinds would be useful.  
Additionally, DHCPv6 servers could determine that a host doesn't need  
stateful information and the stateless information is in RAs, so it  
doesn't have to reply to certain request or requests from certain hosts.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Aug 2007 10:19:08 +0900

Iljitsch van Beijnum wrote:

> IPv6 specifications and implementations  without DHCPv6 have been
> around for the better part of a decade,

Given that IPv6 has never really been deployed, we should rather use
OSI, because it has longer history of specification and implementation.

> so  requiring DHCPv6 now
> seems curious at best. In other words: DHCPv6  should be optional.

ARP, DHCPv4, ND and DHCPv6 are all optional.

So?

> If they tell the host the same thing then obviously we don't need two  

That is, we don't need OSI nor IPv6.

Actually, IPv6 without ND is a little better than IPv4 that it may
worth deploying.

							Masataka Ohta

---

From: James Carlson <[email-masked]>
Date: Tue, 14 Aug 2007 08:43:01 -0400

> It adds up if you have a large number of hosts on a subnet.

I doubt it.  It's something you do just when you're configuring the
interface, and then you're done.

If you're in fact in the state where you can't even bear the load of
configuring the interfaces, then I suspect that neighbor discovery,
DNS, and plain old user data traffic will overwhelm you.  DHCPv6
(using Information Request or Rapid Commit) is just two packets when
the interface is configured.  All those other protocols are going to
add dozens, hundreds, or more for each host.

> a host could serve as both a router solicitation and a DHCP solicit  

I'm not wild about the idea of a single message getting replies from
two separate entities.  I suppose it's doable, but it seems like
needless complexity.  What is being optimized and why?

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781From [email-masked] Sat Aug 18 11:30:48 2007
Date: Tue, 14 Aug 2007 08:43:01 -0400
From: James Carlson <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: Bernie Volz <[email-masked]>
Subject: [dhcwg] Re: prefix length determination for DHCPv6

> It adds up if you have a large number of hosts on a subnet.

I doubt it.  It's something you do just when you're configuring the
interface, and then you're done.

If you're in fact in the state where you can't even bear the load of
configuring the interfaces, then I suspect that neighbor discovery,
DNS, and plain old user data traffic will overwhelm you.  DHCPv6
(using Information Request or Rapid Commit) is just two packets when
the interface is configured.  All those other protocols are going to
add dozens, hundreds, or more for each host.

> a host could serve as both a router solicitation and a DHCP solicit  

I'm not wild about the idea of a single message getting replies from
two separate entities.  I suppose it's doable, but it seems like
needless complexity.  What is being optimized and why?

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677