I would like suggest: 1. Let /64 be the default for DMR; 2. Keep U-byte in the current MAP-T document, referred to RFC6052; 3. RFC 6052 should be updated aligning the outcome of 6man.
Regards, Congxiao 2013/6/6 Rajiv Asati (rajiva) <[email protected]> > It would be reasonable to state it as a recommendation (unless U-octet > gets changed by 6man*), since it is advantageous to be able to find the > encoded IPv4 address relatively easily during troubleshooting. > > * We wouldn't want to wait for that change to happen as a normative > reference. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Ole Troan > > Sent: Thursday, June 06, 2013 9:28 AM > > To: Wojciech Dec > > Cc: Softwires-wg; Congxiao Bao > > Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping > > > > > would like to get your feedback regarding a possible change to the way > > IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, > > http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , > follows > > RFC6052, and sees the IPv4 address inserted after the prefix. This aligns > > naturally with any/all existing NAT64 implementations, i.e. in a > non-shared- > > address domain, a MAP-T CE would work with any regular NAT64 BR. > > > A direct consequence of following RFC6052 is that, in cases where the > > prefix is shorter than /64, it results in some "bit spreading" of the > IPv4 > > address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5 > . > > This is likely to be cumbersome operationally. > > > > > > An option for simplifying this, and the change proposal seeking your > > feedback, would be to specify that the DMR should be a /64 prefix, or at > > least to make a recommendation to that effect in the specification. > > > > given that 6man is removing the special meaning of the U/G bits, perhaps > > RFC6052 should be updated, and MAP-T could ignore the U-byte? > > > > 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
