Hi Remi, On 1/28/13 11:16 AM, "Rémi Després" <[email protected]> wrote:
>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". Honestly, I don¹t know the rationale behind this. > >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. 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
