IPv6 Netowrk Device Numbering BP

Thu Nov 1 12:37:19 UTC 2012

Though 2001:abcd::192:168:10:10 was written in a format with both :
and . , I think would could take the concept mentioned above and
extend it either by making it
2001:abcd::C0:A8:0A:0A
or
2001:abcd::C0A8:0A0A

Doing the latter wastes less space and let's the host use the upper
32bits of the host portion for vhosts.
Ex: 2001:abcd::1:C0A8:0A0A

Should be easy enough as something like pxelinux already squishes your
v4 address down to do file searching on tftp servers.
Ex: /mybootdir/pxelinux.cfg/C000025B for 192.0.2.91

I personally have for this "use the last 32bits of the v6 address for
the v4 dual stack address" trick and was happy with it. Still fits
with the concept of "give each host a /64"

On Thu, Nov 1, 2012 at 8:20 AM, Masataka Ohta
<mohta at necom830.hpcl.titech.ac.jp> wrote:
> Eugeniu Patrascu wrote:
>
>> You can say it's a IPv4 thinking model, but it's easier to remember
>> that if the fileserver it's at 192.168.10.10 then it's IPv6
>> counterpart address would be 2001:abcd::192:168:10:10 (each subnet
>> being a /64)
>
> That is a clever idea except that it can not always follow
> modified EUI-64 format aof rfc4291.
>
> We should better introduce partially decimal format for
> IPv6 addresses or, better, avoid IPv6 entirely.
>
>                                                 Masataka Ohta
>>
>>
>>
>>>
>>> Another option would be to do both. Assign a fixed address and also
>>> let it chose EUI-64. However, I see that leading to confusion. Not
>>> sure what good it would do.
>>>
>>> Is there anything like a standard, best practice for this (yet)?
>>> What are other people doing and their reasons? Anyone have operational
>>> experience with what works and what does not (and the "what does
>>> not" is probably really of more interest)?
>>
>> Letting the host choose it's own IP can be very tricky and has
>> operational hurdles along the way as it's not that easy to copy
>> configurations across devices during upgrades and maintenance swap
>> outs.
>>
>>
>>
>
>

-- 
Zach Giles
zgiles at gmail.com