On Mar 7, 2010, at 5:32 AM, Shon Elliott wrote:
> My first reply to this thread. I've been kind of tracking it.
>
> I would love to move to IPv6. However, the IPv6 addressing, I have to say, is
> really tough to remember and understand for most people. Where is a four
> number
> dotted quad was easy to remember, an IPv6 address.. not so much. I wished they
> had made that a little easier when they were drafting up the protocol specs.
> basically, you need technical knowledge to even understand how the IP address
> is
> split up. I wished ARIN would waive the fee for service provider's first block
> of IPv6 as well. It would help make the dual stack deployment easier.
>
I'm not sure how you think they could have. 128 bits is a really big number
no matter how you represent it. For the most part, attempting to remember
IP addresses of either form is error-prone and ill-advised.
It's actually much easier to understand how an IPv6 address should be split
up than an IPv4 address. The rules are virtually identical to IPv4, and the
recommendations are even easier to understand than the IPv4 rules.
Rule: A netmask is expressed as a / followed by the number of contiguous
bits at the MSB end of the number which comprise the network number. The
remaining bits at the LSB end of the number comprise the host address.
(Hint: This is the same rule as modern IPv4 and has largely the same mapping:
For example, a /8 is 0xff000000 in IPv4 and 0xff00000000000000000000000000 in
IPv6.
(notice just more 0s to the right of the 0xff)
)
Recommendations:
End networks containing hosts should be /64.
End-User organizations of very small size should receive a /56, or, on request,
a /48.
End-User organizations which are not very small should receive a /48, or,
larger with
appropriate justification.
ISPs and LIRs should receive a /32, or, larger with appropriate justification.
Because IPv6 addresses are always represented in hex, it is even easier to match
up subnets to digits. Each hex digit is exactly 4 bits. (In IPv4, every 1, 2,
or 3
digits, separated by a . was 8 bits and required a not insignificant amount of
mental arithmetic to match an IP address and netmask to a prefix)
IPv6 netmasks which do not line up with nibble boundaries still require some
mental arithmetic, but, it is much much easier:
Mask Value (MV) = /xx
XX = Mask match portion of address.
yy... = Remainder of 64 MSb of address.
zz... = Host portion of /64
MV % 4 Mapping:
0 Full digit. /0 = default
1 First bit /1 = [0-7]yyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz
or [8-f]yyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz
2 Two bits /2 = [0-3], [4-7], [8-b], or [c-f]...
3 Three bits /3 = [0-1], [2-3], [4-5], [6-7], [8-9], [a-b], [c-d],
or [e-f]...
0 Full digit /4 = Xyyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz
1 First bit /5 = X[0-7]yy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz
or X[8-f]yy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz
2 Two bits /6 = X[0-3]yy, X[4-7]yy, X[8-b]yy, or X[c-f]yy...
etc.
Personally, I recommend the KISS approach and keeping the boundaries aligned
to the nibble wherever possible (/4, /8, /12, /16...)
> I know IPv4 is running out. I understand the situation. I just wished they had
> put a little more thought into the user experience side of the addressing. You
> can all flog me now if you want. I expect it. I'm green on IPv6. I would love
> the education if I am wrong.
>
I'm not trying to flog you. I'm trying to help you. If you have more questions,
feel free to email me off-list.
Owen
> -S
>
>
> Mark Newton wrote:
>> On 06/03/2010, at 1:06 AM, David Conrad wrote:
>>
>>> Mark,
>>>
>>> On Mar 4, 2010, at 11:46 PM, Mark Newton wrote:
>>>> On 05/03/2010, at 2:50 PM, David Conrad wrote:
>>>>> When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll
>>>>> quickly find that reclaiming pretty much any IPv4 space will quickly
>>>>> become worth the effort.
>>>> Only to the extent that the cost of IPv6 migration exceeds the cost
>>>> of recovering space.
>>> You're remembering to include the cost of migrating both sides, for all
>>> combinations of sides interested in communicating, right? In some cases,
>>> that cost for one of those sides will be quite high.
>>
>> Yes, but I only need to pay the cost of my side.
>>
>>>> There's sure to be an upper-bound on the cost of v4 space, limited by the
>>>> magnitude of effort required to do whatever you want to do without v4.
>>> The interesting question is at what point _can_ you do what you want
>>> without IPv4. It seems obvious that that point will be after the IPv4 free
>>> pool is exhausted, and as such, allocated-but-not-efficiently-used
>>> addresses will likely become worth the effort to reclaim.
>>
>> That isn't a likely outcome, though. We'll never need to do "without IPv4",
>> it'll always be available, just in a SP-NATted form which doesn't work very
>> well.
>>
>> Continuing to put up with that state of affairs comes with its own set of
>> costs and obstacles which need to be weighed up against the cost of
>> migrating to dual-stack (unicast global IPv6 + SPNAT IPv4) to extract
>> yourself
>> from the IPv4 tar-baby. Not migrating will be increasingly expensive
>> over time, the costs of migrating will diminish, each individual operator
>> will reach their own point when staying where they are is more expensive
>> than getting with the program.
>>
>> And most of the participants on this mailing list will probably reach
>> that point sooner than they think.
>>
>> My mom will probably never see a need to move beyond IPv4. But her next
>> door neighbor with the bittorrent client and WoW habit probably will, and
>> any content provider who's interested in having a relationship with their
>> eyeballs which isn't intermediated by bollocky SPNAT boxes probably will too.
>>
>> Horses for courses.
>>
>> What I do know is that this "migrating to IPv6 is expensive so nobody wants
>> to do it," is a canard that's been trotted out for most of the last decade
>> as a justification for doing nothing.
>>
>> As an ISP that's running dual-stack right now, I can tell you from personal
>> experience that the cost impact is grossly overstated, and under the
>> circumstances is probably better off ignored.
>>
>> Just sayin'.
>>
>> - mark
>>
>> --
>> Mark Newton Email: new...@internode.com.au (W)
>> Network Engineer Email: new...@atdot.dotat.org (H)
>> Internode Pty Ltd Desk: +61-8-82282999
>> "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
>>
>>
>>
>>
>>
>>
>>
