On Wed, Oct 1, 2008 at 11:11 PM, Dunn, Jeffrey H. <[EMAIL PROTECTED]> wrote: > I second Brian's points that: > > 1. DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed > 2. Basically, in the absence of the ability to subnet arbitrarily (on > non-64 bit boundaries), I'm at the mercy of my upstream. >
3rd. > Further, I would like to summarize the reasons offered on this list for > proscribing all but 64-bit prefixes: > > 1. That is the way the prefix is currently defined in mu favorite RFC > 2. We have always done it that way > 3. The decision was made 12 years ago and the explanation is in a book > > None of these appear to be a compelling ENGINEERING reason to require > 64-bit prefixes be the only acceptable option. > I believe part of the reason was that cidr was 'hard' and the percieved burden on operations folks to do subnetting not on bit boundaries drove the current /32, /48, /64 decisions. I think most operations folks have a grasp of the basics, we can really just move along and let people do what they will with their networks, eh? As to the dhcp or auto-conf discussion, there are situations where autoconf is not sufficient, dhcp is part of operations today, it's going to continue to be going forward. Disappearing dhcpv6 is really not going to help uptake in enterprise situations, forcing folks to manage 2 completely disparate methods of addressing on their deployed systems is only going to keep people from deploying the 'new' and 'adds pain' way. -Chris > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > (301) 448-6965 (mobile) > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Brian Dickson > Sent: Wednesday, October 01, 2008 4:42 PM > To: TJ > Cc: 'IETF IPv6 Mailing List' > Subject: Re: what problem is solved by proscribing non-64 bit prefixes? > > TJ wrote: >>>> further on the wireless interface. For IPv6, although it receives > a >>>> huge /64 IPv6 prefix on the wire it can't offer Stateless > Autoconfig >>>> on the wireless interface. This begs again for IPv6 NAT. >>>> >>> I'd say it begs for assigning the user a /56 or /48 routed to them > on the >>> /64 link. >>> >> >> Exactly right! >> >> A /56 to the home's DHCPv6-PD capable CPE. >> (Atleast) one "inside" segment (couple of switch ports, maybe an > antenna or >> two) for now - sporting SLAAC, maybe Stateless DHCPv6 as well? >> A healthy dose of stateful IPv6 firewalling, for those so inclined. >> Oh, and probably the same IPv4/NAT/FW we all know and love. >> Winner. >> > > The problem, fundamentally, is one's position in a hierarchy (of IPv6 > assignments or pd's). > > In many markets, there is a (very) limited pool of ISPs (let along ISPs > offering IPv6 !!). > > And, consequently, the ability to ask for and receive something other > than a single /64, > is limited by the availability of ISPs in the local pool who offer it. > It doesn't much matter whether > the assignment of a /64 is dynamic or static - either way it bites. > > There is no guarantee that even a *single* ISP in any particular pool > of > local ISPs, has enough > clue to offer this, or the ability to offer it (regardless of reason > underlying the inability). > > This isn't something I, as a customer, have *direct* control over, and > I > may not have an alternative (other ISP offering what I want). > > And it doesn't matter *why*. > > In such a situation, I am effectively "painted into a corner" (e.g. > when > viewing IPv6 space as a Heat Map / Hilbert curve). > > "Bits to the left of me, Bits to the right, Here I am - Stuck in the > middle again". > (Apologies to the original artist and those who don't like puns.) > > The question is, what does one do in such a scenario, and/or what *can* > one do? > > If the ability to do what one wants, is permitted by non-64 bit > prefixes, life is good. > DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed for > this. > > If only 64-bit prefixes can be used, then one gets only one 64-bit > prefix to use for everything. Good luck with that. > > Basically, in the absence of the ability to subnet arbitrarily (on > non-64 bit boundaries), I'm at the mercy of my upstream. > > 128 bits doesn't look so wonderful in such a scenario, I would surmise. > > Nobody is a winner. :-( > > Brian > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
