Let's not leave anything in the drafts as loose-ends for the readers (e.g. Implementors, designers, architects) to (mis)interpret.
We better provide recommendations, if/as needed in case of ambiguity or disagreement. IMO, /64 (or less) usage for end-user prefix is better off as a MAP (-E) recommendation, but not as an enforcement. Cheers, Rajiv Sent from my Phone On Jan 28, 2013, at 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
