I like Carsten's proposal because it enables - yet does not force- the
use the 111 bits prefix. There are many places where the /64 is assumed
and it's good to be able to use it when that's a constraint on the
deployment.

Pascal


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Carsten Bormann
> Sent: Monday, March 29, 2010 5:35 PM
> To: [email protected]
> Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses
> 
> On Mar 29, 2010, at 17:10, 6lowpan issue tracker wrote:
> 
> > (0000:0000:0001:xxxx), where xxxx is the short address.
> 
> I didn't quite understand from the Discussion in Anaheim what is
better
> about
> 
> ::1:xxxx
> 
> than
> 
> ::ff:fe00:xxxx
> 
> If we can stick to the latter, we don't really have to change 4944.
> 
> In favor of preparing a lasting fix for 4944, I would make the
following change
> to -06:
> 
> > The reconstituted address is built from the 16-bit address xxxx by
> >
> > 1) computing the address:
> >
> > ::ff:fe00:xxxx
> >
> > 2) replacing the bits in this address by the bits actually given by
the prefix in
> the context.
> >
> > In other words, the prefix in the context overrides the address
generated
> by step 1.
> > For example, if 64-bit prefix pppp:pppp:pppp:pppp is given, the
result is:
> >
> > pppp:pppp:pppp:pppp::ff:fe00:xxxx
> >
> > while if a 112-bit prefix nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn is
given,
> the result is:
> >
> > nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:xxxx
> 
> Gruesse, Carsten
> 
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to