[ppml] IPv6 & /48 [was 2005-1:Business Need for PI Assignments]

[Randy Bush]

>> just to throw in a serious bomb, there is no actual real technical
>> reason for the /64 magic boundary.  it's one of the last big pieces
>> of the old v6 religion.  but beware that it does have some ties to
>> ether-like mac addresses and hence auto-numbering.
> 
> I think early on people talked about having 64-bit ip addressed and then
> talked about easy load-balancing and allowing multiple devices to have
> same 64-bit internet (ISP assigned) ip address with multiple actual
> devices at the end that have different physical addresses. That ended up
> being 128bit address with first 64bits designated for internet routing and
> last 64bits being unique device id. Entire 64bit for device id is because
> currently we use /48 MACs and extra /16 was added just in case as well as
> to allow for different MAC-like (or not like) device-id addressing systems
> (and BTW with /48 bits there and many more network cards sold then we have
> internet- connected machines we still have not come close to exhausting
> those addresses) Now possibly future astronauts and nanotech-engineers
> will find a better use for those last /64 bits (and they will then thank
> use for leaving those 64 bits open) but lets not worry about that right
> now because the most important thing we need to do is to actually help get
> ipv6 deployed.
> 
> As far as why /48 for end-networks that was decision done not only by IETF 
> but also discussed at all RIRs - I remember we had voted for that on at 
> least two ARIN meetings in around 2000-2002 (I think Las Vegas was when it 
> was finalized) and there was a consensus about it. It can be changed, but 
> it'd have to be the same kind of process with everyone getting involved 
> and agreeing on the change and it would cause yet another push of ip6 
> deployment by several years. Plus I really don't see why we should be 
> worrying about it when just for case like that it was decided that only 
> 1/4 of ipv6 space will actually be open for use and rest 3/4 are reserved 
> in case we ever actually exhaust the first 1/4 and then if we do we can 
> surely work out a lot more serious policies as to how not to exhaust 
> remaining 3/4 quickly...

so, if i rephrase that there is no real CURRENT technical reason, i
gather you aree.  interesting side note that the binding to a mac
address created all sorts of privacy issues as well, see later
back-patches to v6 such as 3041.

randy