Remi, >> 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".
I am not aware of any implementations that restrict the prefix length to 64. I'm not aware of any implementation that applies any meaning to any bits in the interface-id. I'm aware of operators using prefix lengths longer than /64. actual deployment and implementation trumps text. that doesn't even use RFC2119 language. (and I know after annual discussions with one of the authors that the intention with that line was not to make IPv6 classful.) > > 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? that's up to the operator. > - And to the IPv4 address if the prefix is longer than /68? it gets overwritten by the prefix, isn't that what the text says? > - ... > > 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. huh? provider wants to deploy with a prefix length of 128? single tunnel end point address. isn't that obvious? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
