Subject: RE: [dhcwg] DHCPv6 Client address prefix

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 21 Aug 2008 18:59:07 -0400

Dream on, DHC folks who have said adding a prefix len option to DHCPv6
makes sense. I will personally not let that happen. 

As I have said earlier, please go and read my emails to this mailer as
to why I say such ideas don't make sense.  Since we have discussed such
issues copiously in the past year, I am not going to waste my time
repeating myself.  All I will do is jump is soon as a set of emails fly
by saying adding a prefix length to DHCPv6 makes sense.  It SO DOES NOT.

Also, cc such emails to 6man because by design it's ND in IPv6 that
deals with prefix length.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mike Taylor
Sent: Thursday, August 21, 2008 6:02 PM
To: Ralph Droms (rdroms); 'Bud Millwood'
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Client address prefix

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Ralph Droms
> Sent: Thursday, August 21, 2008 2:55 PM
> To: Bud Millwood
> Cc: [email-masked]; Ralph Droms
> Subject: Re: [dhcwg] DHCPv6 Client address prefix
> 
> Bud - I agree with your conclusion about whether prefix information 
> could reasonably be carried in DHCPv6.
> 
> The IETF has decided that ND is used to provide the information about 
> what prefixes are on a link, under the assumption that RAs are always 
> available and the design decision that two ways to provide the prefix 
> information (RAs and DHCP) is redundant and is an opportunity for 
> misconfiguration.
> 
> There is a scenario - no RAs and no on-link assumption - in which a 
> host needs another mechanism to obtain information about prefixes.
> It's up to the IETF to decide whether DHCPv6 should be extended to 
> solve this problem.

As I understand it, the hard line on this is that a host shouldn't even
use DHCPv6 unless it gets router advertisements with the M bit set.  I'm
not saying I support this viewpoint (or that I don't, I'm not a network
admin) only that this is what I was told in another email.  

/Mike

> 
> - Ralph
> 
> On Aug 21, 2008, at Aug 21, 2008,4:33 PM, Bud Millwood wrote:
> 
> > On Thursday 21 August 2008, Ralph Droms wrote:
> >> I look at this prefix issue somewhat differently.
> >>
> >> As I read the IPv6 specs, there is no prefix length associated with

> >> an address, per se.  When used as a destination address for 
> >> datagram forwarding, the address is used as a string of 128 bits, 
> >> and compared against the entries in the host forwarding table.  
> >> Each of those entries has an associated prefix length, which is 
> >> used to decide how many bits of the destination address and 
> >> forwarding table entry should be compared.  So, in my opinion, 
> >> there is a prefix length for each forwarding table entry, but no 
> >> prefix length associated with an address.
> >
> > There are a lot of options in DHCPv4 that aren't directly associated

> > with a specific IP address. Could it not be argued that DHCPv4 was 
> > not just about assigning an address, but also very much about 
> > configuring a complete network stack? That regardless of how DHCPv4 
> > was percieved, in effect it was a network stack configuration 
> > server?
> >
> > If DHCPv6 were viewed the same way, then it would make sense to 
> > transmit a prefix length, but *not* with an IAADDR - with a new IA 
> > network- config type or something. In that case, clients could opt 
> > to request such information during first stage initialization, but 
> > maybe not when simply extending address leases.
> >
> > - Bud
> >
> >> Now, as a matter of convenience or perhaps as a carryover from IPv4

> >> implementations, it seems many stacks allow the specification of a 
> >> prefix length with an address assigned to a device interface.  This

> >> same thinking is sometimes used to call for the inclusion of a 
> >> prefix length with addresses assigned by DHCPv6.  In these cases, 
> >> the device stack assumes that the prefix derived from the assigned 
> >> address and prefix length is on-link and an entry for that derived 
> >> prefix is added to the device forwarding table.  In theory, I think

> >> this action is wrong.  Based on my understanding that there is no 
> >> prefix associated with an address, there is no need to specify a 
> >> prefix when assigning an address to an interface (either manually 
> >> or through DHCPv6).
> >>
> >> The IETF decided that prefix information should be provided to 
> >> devices through RAs.  I understand this decision, as the assignment

> >> of addresses to an interface in a device is entirely separate from 
> >> the notion that a prefix is associated with a link.
> >>
> >> The recent change to the assumption that addresses are on-link now 
> >> causes problems in the case where no RAs are provided to a device.
> >> If
> >> the IETF chooses to address this problem, the correct solution 
> >> would be to provide complete prefix information (either by carrying

> >> PIOs in
> >> DHCPv6 or carrying the necessary information in some other new 
> >> option).  Associating a prefix length with assigned addresses might

> >> provide some help but would not be a correct solution.
> >>
> >> - Ralph
> >>
> >> On Aug 21, 2008, at Aug 21, 2008,11:11 AM, David W. Hankins wrote:
> >>> On Wed, Aug 20, 2008 at 08:40:31PM -0400, Hemant Singh (shemant)
> >>>
> >>> wrote:
> >>>> /64 is only mandated to be a default prefix length for SLAAC 
> >>>> clients.  A
> >>>> DHCPv6 client cannot assume a /64.  Also check the IETF 6man 
> >>>> mailer for
> >>>
> >>> It also cannot assume a /128, as this results in non- 
> >>> interoperability.
> >>>
> >>> This is a problem we could easily clear up by including a simple 
> >>> prefix length along with the IAADDR; in its absence, you can now 
> >>> safely assume a /128 was intended by the network operator.  In its

> >>> presence, you still interoperate.
> >>>
> >>> I'm probably going to make such an option in ISC's VSIO space, but

> >>> I cannot assume the same thing.  Someone who doesn't know about 
> >>> ISC's peculiar VSIO's can't be expected to set our prefix length, 
> >>> so we will have to retain a compatible default.
> >>>
> >>>
> >>> The criticism however is that merely the prefix length is an 
> >>> incomplete set of information; the suggestion is to include the 
> >>> full PIO contents in DHCPv6 replies.
> >>>
> >>> I don't fully understand the suggestion, as it has something to do

> >>> with "not on link" prefixes, which are supposed to mean that 
> >>> although you're all on the same broadcast domain you're still 
> >>> expected to send your packets through a default router to reach 
> >>> each other.  This seems equivalent in results to setting /128 to 
> >>> me, but I guess the bit wouldn't be in the PIO if there weren't 
> >>> some important distinction.
> >>>
> >>> --
> >>> Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
> >>> Why settle for the lesser evil?
https://secure.isc.org/store/t-shirt/
> >>> --
> >>> 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
> >>> _______________________________________________
> >>> dhcwg mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/dhcwg
> >>
> >> _______________________________________________
> >> dhcwg mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dhcwg
> >
> >
> >
> > --
> > Bud Millwood
> > Weird Solutions, Inc.
> > http://www.weird-solutions.com
> > tel: +46 8 758 3700
> > fax: +46 8 758 3687
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

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