[121714] in North American Network Operators' Group
Re: Using /126 for IPv6 router links
daemon@ATHENA.MIT.EDU (Tim Durack)
Mon Jan 25 14:03:08 2010
In-Reply-To: <009901ca9de8$64fff530$2effdf90$@com>
Date: Mon, 25 Jan 2010 14:02:40 -0500
From: Tim Durack <tdurack@gmail.com>
To: TJ <trejrco@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mon, Jan 25, 2010 at 1:01 PM, TJ <trejrco@gmail.com> wrote:
>> -----Original Message-----
>> From: Richard A Steenbergen [mailto:ras@e-gerbil.net]
>> Sent: Monday, January 25, 2010 12:08
>> To: TJ
>> Cc: nanog@nanog.org
>> Subject: Re: Using /126 for IPv6 router links
>>
>> On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote:
>> > While I agree with parts of what you are saying - that using the "simp=
le
>> > 2^128" math can be misleading, let's be clear on a few things:
>> > *) 2^61 is still very, very big. =A0That is the number of IPv6 network
>> > segments available within 2000::/3.
>> > *) An end-user should get something between a /48 and a /56, _maybe_ a=
s
> low
>> > as a /60 ... hopefully never a /64. =A0Really.
>> > **) Let's call the /48s enterprise assignments, and the /56s home
>> > assignments ... ?
>> > **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments.
>>
>> It is if we are to follow the "always use a /64 as a single IP"
>> guidelines. Not that I'm encouraging this, I'm just saying this is what
>> we're told to do with the space. I for one have this little protocol
>> called DHCP that does IP assignments along with a bunch of other things
>> that I need anyways, so I'm more than happy to take a single /64 for
>> house as a single lan segment (well, never minding the fact that my
>> house has a /48).
>
> Interesting. =A0I have never seen anyone say "always use a /64 as a singl=
e IP"
> ... perhaps you mean as an IP segment or link?
> You are assigned a /64 if it is "known" that you only need one segment,
> which yields as many IPs as you want (18BillionBillion or so) - and the
> reality is that a home user should get a /56 and an enterprise should get=
a
> /48, at the very least - some would say a /48 per site.
>
>
>> > **) And, using the expected /48-/56, the numbers are really 256-64k
> subnets.
>> ...
>> > Note: "All we've really done is buy ourselves an 8 to 16 bit improveme=
nt
> at
>> > every level of allocation space"
>> > *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal??
>>
>> I'm not saying that 8-16 bits isn't an improvement, but it's a far cry
>> from the bazillions of numbers everyone makes IPv6 out to be. By the
>> time you figure in the overhead of autoconfiguration, restrictive
>> initial deployments, and the "now that the space is much bigger, we
>> should be reallocating bigger blocks" logic at every layer of
>> redistribution, that is what you're left with. So far all we've really
>> done with v6 is created a flashback to the days when every end user
>> could get a /24 just by asking, every enterprise could get a /16 just by
>> asking, and every big network could get a /8 just by asking, just bit
>> shifted a little bit. That's all well and good, but it isn't a
>> bazillion. :)
>
> There are some similarities between IPv6 and old classful addressing, but
> the bit-boundaries chosen were intentionally made big and specifically
> factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). =A0T=
he
> scale of the difference *is* the difference. =A0I am not quite sure what =
a
> bazillion is, but when we get into the Billion Billion range I think that=
is
> close enough! :)
>
>
> /TJ
>
>
>
2^128 is a "very big number." However, from a network engineering
perspective, IPv6 is really only 64bits of network address space. 2^64
is still a "very big number."
An end-user assignment /48 is really only 2^16 networks. That's not
very big once you start planning a human-friendly repeatable number
plan.
An ISP allocation is /32, which is only 2^16 /48s. Again, not that big.
Once you start planning a practical address plan, IPv6 isn't as big as
everybody keeps saying...
--=20
Tim:>
Sent from Brooklyn, NY, United States
