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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Taylor Sent: Thursday, August 21, 2008 6:02 PM To: Ralph Droms (rdroms); 'Bud Millwood' Cc: [EMAIL PROTECTED] Subject: Re: [dhcwg] DHCPv6 Client address prefix > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Ralph Droms > Sent: Thursday, August 21, 2008 2:55 PM > To: Bud Millwood > Cc: [EMAIL PROTECTED]; 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 PROTECTED] > >>> https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> _______________________________________________ > >> dhcwg mailing list > >> [EMAIL PROTECTED] > >> 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 PROTECTED] > > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
