[ppml] IPv6 & /48

[Marshall Eubanks]

On Mon, 25 Apr 2005 16:21:46 -0700 (PDT)
 Lea Roberts <lea.roberts at stanford.edu> wrote:
> it looks like Randy's bomb has produced some reverberations (thanks,
> Randy!  :-)
> 
> in any case, while I haven't looked at the embeded RP that closely, I'm
> assuming that as long as we stay above /64 there shouldn't be a problem?
> (i.e. it doesn't depend on the /48 to work?)

The details are in RFC3956
http://www.ietf.org/rfc/rfc3956.txt

Remember, multicast addresses don't have MAC embedding.

A full (up to 64 bits) unicast RP address is embedded in a full 128
bit multicast address with the potential of setting the 4 bits at the
end - i.e., no attempt is made to embed the Mac address.
This takes 96 bits with overhead.

Regards
Marshall 


> 
> thanks,   /Lea
> 
> On Mon, 25 Apr 2005, Marshall Eubanks wrote:
> 
> > On Mon, 25 Apr 2005 14:08:29 -0700 (PDT)
> >  "william(at)elan.net" <william at elan.net> wrote:
> > >
> > > On Mon, 25 Apr 2005, Randy Bush wrote:
> > >
> > > > 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.
> > >
> >
> > I think that IPv6 embedded RP multicast has shown that you can do cool things
> > in IPv6 because you can embed an address (with some restrictions)
> > completely inside of another one.
> > (In embedded RP, what's embedded is the address of the RP for the multicast
> > group, which means that interdomain ASM multicast can be done without a raft of protocol
> > infrastructure, like MSDP.)
> >
> > I have a feeling that people will find other uses for those bits fairly quickly if IPv6
> > takes off.
> >
> > Regards
> > Marshall Eubanks
> >
> > > 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...
> > >
> > > --
> > > William Leibzon
> > > Elan Networks
> > > william at elan.net
> >
> 
>