2013-01-28 17:36, Senthil Sivakumar (ssenthil) <[email protected]> : ... >> 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". > > Honestly, I don¹t know the rationale behind this.
I wasn't present when this was written but can see that, at least, it made IIDs of LAN interfaces to be unique if based on MAC addresses that are assigned by LAN adapters by vendors in compliance with IEEE rules. This is AFAIK used by default in major OSes. > >> >> The draft says that: >> (a) The PSID is: >> +--+---+---+---+---+---+---+---+---+ >> |PL| 8 16 24 32 40 48 56 | >> +--+---+---+---+---+---+---+---+---+ >> |64| u | IPv4 address | PSID | 0 | >> +--+---+---+---+---+---+---+---+---+ > > I believe this figure is misleading by placing the IPv4 address in a fixed > location. Figure 3 and Figure 7 > In the draft shows that the IID is not in a fixed location. Also, the text > surrounding the above figure 8, says > "The Interface identifier format of a MAP node is based on the format > specified in section 2.2 of [RFC6052], with the added PSID field if > present, as shown in figure Figure 8." > > > But RFC 6052 doesn¹t have the IPv4 address in a fixed location as per > section 2.2. So I think this figure is misleading. > > > > > | n bits | o bits | s bits | 128-n-o-s bits | > +--------------------+-----------+---------+------------+----------+ > | Rule IPv6 prefix | EA bits |subnet ID| interface ID | > +--------------------+-----------+---------+-----------------------+ > > >> (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: > > True. >> - What happens to the u octet? > > I guess that needs to be made clear in the draft. We struggled with that > in our implementation. > > >> - And to the IPv4 address if the prefix is longer than /68? >> - ... >> >> 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. > > I would like to see the IPv4 address be present from bits 96-127, no need > for the PSID to be repeated again. That would allow us to go upto /96 and > being consistent with RFC 6052 which allows one to configure a prefix of > upto /96. Even simpler: don't repeat IPv4 addresses anywhere in IIDs. - IPv4 are already available in encapsulated IPv4 headers, at fixed places - With IPv4 addresses in IIDs, different treatments and interpretations are needed for CEs that are assigned IPv4 prefixes shorter than /32: . Zero padding up to 32 bits . No way in the IID itself to determine that the IPv4 address field contains a source or destination prefix as opposed to the source or destination IPv4 address. Regards, RD > > Thanks > Senthil > >> >> >> 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
