I also tend to not favor "that's the way we have always done it" type of arguments.
In this case, however, I just see it in an operational and pragmatic perspective - 1) I fail to see the need for more subnet bits, based on current deployment plans calling for /48s or /56s per client 2) I certainly see an operational pain point for all current vendors, providers and environments that currently support/provide/use IPv6 3) Nothing stops you from breaking the RFC and doing arbitrary bit length subnets now, as long as you are willing to endure the pain involved Additionally, if longer prefixes are normalized, what would prevent providers from adjusting their allocations accordingly and the end-users gaining nothing? (i.e. - instead of assigning /56s to support /64s, they would simply assign /108s to support /112s or somesuch.) ((or, at the very least, they could switch from assigning /56s to /64s and thus -requiring- (versus "enabling") you to do this type of subnetting)) /TJ >-----Original Message----- >From: Dunn, Jeffrey H. [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 01, 2008 11:11 PM >To: Brian Dickson; TJ >Cc: IETF IPv6 Mailing List; Dunn, Jeffrey H.; >[EMAIL PROTECTED]; Martin, Cynthia E. >Subject: RE: what problem is solved by proscribing non-64 bit prefixes? > >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. > >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. > >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 --------------------------------------------------------------------
