On Sun, 21 Oct 2007 13:22:08 +0200 Jeroen Massar <[EMAIL PROTECTED]> wrote:
> Hi, > > I just noticed > http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf > and found some serious flaws and most likely misunderstandings in the > way that some things are presented in there. It was already publicly > presented at the NANOG meeting, so lets discuss ;) > > <insert humble mode disclaimer etc /> > Slide 2: "We can’t fault the IETF - they aren’t operators" Some of us are. We've also run Novell IPX, Appletalk or DECNet networks in the past, with fixed length node addressing, and would love to have it back. No more too small subnets because you didn't guess right in the first place, no more incorrect subnet masks, no more double hops via a router on the same link because you've had to add a secondary subnet to a link to avoid renumbering, no more remembering to larger (or smaller) subnets, no more early mornings or late nights outside of business or critical use hours fixing all of those things ... > ======= > Slide 4: 2000::/3 are indeed only 125 bits, but this is done so that if > 2000::/3 turns out to be a mistake that another of the 8 /3's can be > chosen to start again, and improve on it. As such, only using 2000::/3 > at the moment is a great thing. Indeed this will most likely then create > a bit of a "Class A" situation, but most very likely it is going to be > just fun. > > ======= > Slide 9: Of course you can ignore it, just use DHCP. Only fe80::/10 is > fixed to use EUI-64 at the moment. Everything else, if you want can be > done with /126's if you really want. But that defies the whole idea of > stateless autoconfiguration. Nevertheless, if you really want, you can. > > But why would you? As an ISP you go to your RIR and the RIR allocates > you a block of address space (generally a /32 or much larger) based on > how many customers you expect to have times /48 + some HD-based overhead. > > As such, you as an ISP will get more than enough address space. > > ======== > Slide 10/11: You don't reserve any bits for customers. They are already > getting a /48 which should be *way more than sufficient* for their > purposes. If they really will need more than 65536 /64 based networks > they will already have such a large network now, and thus can tell you > "hey we need a /47" or something, or they will at a certain point run > out and come back and you give them another /48, which does not really > have to be consecutive. Most of those very large networks though will > simply request PI space. As such they are not your worries. > > If you are reserving space you clearly misunderstood the whole idea of > the /48's. > > Also, there have been plans already (eg by Thomas Nartens) to make the > default assignment size /56 to end-users. Companies would still get > /48's though. > > > Why would this "squeeze the ISP?", you can get as much space from your > RIR as you require. Same as for IPv4. Justify and receive. > > ====== > Slide 12: IMHO you indeed really don't get it ;) > > Does it matter if you have /40's routed to your distinct PoPs, thus > geo-aggregated, and then route /48's from each PoP to the customer, or > make this a difference when you make that into /48's and /64's > respectively? The route count will remain the same. > > Note also that there are still not 1000 IPv6 prefixes globally... > > ==== > > I won't even go in on the rest of the slides, as the above already make > all your assumptions for the rest broken... > > Greets, > Jeroen > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
