Is there an analogy to IPv4? The closest fit for those scenarios, off the top of my head, is to add a layer of NAT. If you were willing to accept the added layer of NAT for IPv4, is there a reason you wouldn't accept an IPv6 "proxy + ULA's behind it" deployment? Failing that, I suppose you could do transparent bridging, but that should almost never be the first answer :). A more advanced option would be DHCPv6-PD, but the level of support for that is not quite 100% yet.
One of the design goals with IPv6 is to actually give you more address space than you currently know you need, specifically to avoid these problems ... and if done right it could literally be as simple as your upstream (be it a provider, or a layer higher in your org, etc.) making the route pointing at you a /63 instead of a /64 (or /55 instead of /56, etc.) ... aggregation / summarizability is a Good Thing also :). >From the SysAdmin perspective, the network people allocating your space would, ideally, have a sequential additional block they could hand you and you'd be all set. If they failed to (atleast attempt to) maintain that sort of flexibility, slap them on the wrist and take a non-sequential block ... It's actually a bit ironic, one of IPv6's strengths is it's extensibility :). /TJ >-----Original Message----- >From: Alexandru Petrescu [mailto:[EMAIL PROTECTED] >Sent: Wednesday, October 01, 2008 12:57 PM >To: TJ >Cc: 'IETF IPv6 Mailing List' >Subject: Re: Why would anyone want to use a 64 bit interface identifier? > >TJ wrote: >>> "yet it's hard to extend a common IPv6 subnet" >> >> I'm sorry, extend in what fashion? You mean in order to have 2 (or, >> "n") subnets? > >Yes, that, it's hard to add a new unplanned-for-initially Ethernet subnet to >an existing subnet which is allocated a /64 prefix. > >>> "or one needs to be allocated a shorter than /64 prefix (e.g. be >>> allocated a /56). These are rare" >> >> They are? I must have missed that memo! (Sorry, don't mean to be >> overly flippant) Seriously, last time I checked I could get up to a >> /48 (or, atleast a /56) fairly readily ... that is the whole point, >> and if someone is making that difficult for you that is a different >> conversation! > >Well yes, I suppose if one asks an allocating organization for a /48 prefix >then one may obtain it easily. However, one must be sysadmin to know one >can obtain that. A more mere mortal doesn't even know such organizations >exist, and uses whatever is available at hand. There are more mere mortals >than sysadmins, hence that is rare. > >If I arrive to a /64 wifi hotspot in a hotel room I can't extend it with >another subnet, on which to plug my other IPv6 wifi devices. > >Also, if I plan my (fictitious) lab network with core routers and such and >prepare for 15 edge /64bit networks, I won't be able to extend them in a few >years with more edge networks without manually changing the addressing in >the core routers. > >If I want to build a WiFi router (not bridge), which plugs itself into an >IPv6 wired network, autoconfigures itself, and delivers IPv6 on the wifi >part - it's hardly possible, because the IPv6 wired network on which I plug >this AP is hardly extensible. > >People have already deployed many /64 Ethernet networks - they're all hard >to extend. > >This is lack of extensibility, itches me, > >Alex > >> >> >> /TJ >> >> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, >>> 2008 12:09 PM To: TJ Cc: 'IETF IPv6 Mailing List' Subject: Re: Why >>> would anyone want to use a 64 bit interface identifier? >>> >>> TJ wrote: >>>>> I speculate that one possible reason for this was to design a SLAAC >>>>> over Ethernet that is reliable, simple, universal and >>>>> straightforward to implement. >>>> BINGO. And those are all (IMHO) Good Things. >>> Well yes, they're Good Things. >>> >>>>> In a way, I see SLAAC to have become so popular as opposed to DHCP. >>>>> Were DHCPv6 more developed we wouldn't have this IID-64bit problem, >>>>> I >>>> think. >>>> >>>> We could debate how "popular" SLAAC is (many of those arguments, >>>> both pro and con, are environment / deployment specific), but more >>>> relevant - some DHCP implementations also assume a 64b IID. >>> I think I agree. >>> >>>> Which aspect is the cart and which is the horse could also be >>>> debated, but the real point is - again - that this assumption has >>>> been baked-in to so many things that changing it is (yes, still >>>> IMHO) a Bad Thing. >>> Well of course, one wouldn't dare suggest changing such deeply >>> entrenched std and implementation, bar the deployed base. >>> >>> However, one can't stop oneself express the strong frustration felt >>> about extending an IPv6 network. With all the great SLAAC features >>> and software availability - yet it's hard to extend a common IPv6 >>> subnet: one needs DHCPv6 prefix delegation be in place, or one needs >>> to be >> allocated >>> a shorter than /64 prefix (e.g. be allocated a /56). These are rare. >>> >>> Thanks for the message, I'll go in listening mode :-) >>> >>> Alex >>> >>> _____________________________________________________________________ >>> _ 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 protected] Administrative >> Requests: https://www.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 protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
