Hi, Linda, 2013-01-29 à 07:54, [email protected] a écrit :
> > Hi,Remi > > > [email protected] 写于 2013-01-29 00:16:32: > > > Senthil, > > > > > > 2013-01-2815:24, Senthil Sivakumar (ssenthil) <[email protected]> : > > > > > I believe the prefix length > 64 should be allowed. > > > > > > > It is upto the > > > operator to choose the prefix length of their choice. > > > > Agreed. > > No one suggest to say the contrary. > > > > Yet, operators have the constraint of RFC 4291 that "For all unicast > > addresses, except those that start with the binary value 000, > > Interface IDs are required to be 64 bits long and to be constructed > > in Modified EUI-64 format". > > > > The draft says that: > > (a) The PSID is: > > +--+---+---+---+---+---+---+---+---+ > > |PL| 8 16 24 32 40 48 56 | > > +--+---+---+---+---+---+---+---+---+ > > |64| u | IPv4 address | PSID | 0 | > > +--+---+---+---+---+---+---+---+---+ > > (b) "If the End-user IPv6 prefix length is larger than 64, the most > > significant parts of the interface identifier is overwritten by the prefix." > > > > This is particularly unclear: > > - What happens to the u octet? > > - And to the IPv4 address if the prefix is longer than /68? > > Remi, you mean the prefix is longer than /68 or /78? Oops, I meant longer than 64 + 8, i.e. 72. Thank you. > I think /68(64+4) prefix doesn't overwrite IPv4 address. > > BRs > Linda Wang > > > > - ... > > > > Of course, if a use case is provided where MAP-E would be actually > > used with an IID shorter than 64 bits, it should be discussed. But: > > - There is no such use case so far. > > - Looking for one doesn't seem useful. > > > > > > Regards, > > RD > > > > > > > > > > On 1/28/13 8:59 AM, "Ole Troan" <[email protected]> wrote: > > > > > >>>>> > > >>>>> The examples in my previous note sort of provided backing for my view > > >>>>> that the MAP endpoint IPv6 prefix can be limited to a maximum of a > > >>>>> /64, thus making the IID fully conformant both to RFC 4291 and to RFC > > >>>>> 6052. > > >>>>> > > >>> ... > > >>> > > >>>>> > > >>>>> I think limiting the prefix length to 64 bits is reasonable. Comments? > > >>>> > > >>>> I don't think that's reasonable. > > >>>> and I don't see what it buys us, given that supporting prefix lengths > > >>>> longer than 64 is simple. > > >>>> IPv6 isn't classfull, there isn't anything magic with the 64 boundary. > > >>>> ;-) > > >>>> > > >>>> cheers, > > >>>> Ole > > >>>> > > >>> > > >>> OK, then I agree with Rémi. Drop mention of prefixes greater than 64 > > >>> bits long and leave it to the reader to judge whether RFC 4291 imposes a > > >>> limit. > > >> > > >> you want this removed: > > >> <t>If the End-user IPv6 prefix length is larger than 64, the most > > >> significant parts of the interface identifier is overwritten by the > > >> prefix.</t> > > >> > > >> I disagree. this is the only text in there suggesting to an implementor > > >> that prefix lengths can be any value between 0-128. > > >> > > >> Tom, Remi and I have stated our opinions. does anyone else have a view on > > >> the matter? > > >> > > >> cheers, > > >> Ole > > >> _______________________________________________ > > >> Softwires mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/softwires > > > > > > _______________________________________________ > > > Softwires mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
