In message <[EMAIL PROTECTED]>, Alexandru Petrescu writes:
> 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.

        CPE equipement will just make PD requests upstream and
        will accept PD requests from down stream.

        You plug you router in and it just requests a /64 prefix.
        If something downstream requests a /64 prefix you it would
        then request an additional /64 prefix.  The router would
        just remember which prefixes were handed out and route traffic
        accordingly.

        A ISP for example would hand out up to 256 prefixes this way
        if their policy was for /56.

        A hotel would have /48 to hand out prefixes to customers from.
        If they have more than 65k rooms they request a bigger prefix.

        If you do it correctly the same router will get the same prefix
        repeatedly as the prefix ids in the PD requests won't change.

> 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
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to