Hi, Washam, Thanks for your detailed questions and comments. Answers and further comments in line.
Le 2012-03-11 à 10:48, Washam Fan a écrit : > Hi, > > Eventually I get a chance to review this version and have some major > comments and questions as below. > > 1. Relationship with MAP, MAP-T, MAP-E. > I thought, MAP was expected to be a generic algorithm for stateless > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, > MAP would apply to MAP-T, MAP-E as well as 4rd-u. The point is that 4rd-u unifies not only the address format for -T and -E, but also the header format so that a single standard becomes sufficient. The 4rd-U technique for this was presented in Taipei, but it didn't arise interest in the MAP team. Design of 4rd-u had then to become autonomous. > But draft 4rd-u-04 > doesn't mention MAP draft. 4rd-u is proposed as an alternative to the 2-standards approach of MAP. It therefore needs only needs a historical reference to MAP, which is done in sec. 8. > And I see the mapping rules stuff in the > draft overlapped with MAP. Confused. > > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. > Would you mind expaund on what benefits 4rd-u can gain exclusively? > Ideally, there would be a seperate section or even a seperate draft > for such comparison. As announced, an update of draft-despres-softwire-stateless-analysis-tool will contain a comparison (now to be posted very soon). An earlier comparison table was available in http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to use IPv6-only middle boxes for deep packet inspection and web caches; also, like MAP-E, it ensures full IPv4 transparency. > 2. NAT64+ stuff. > My understanding, NAT64+ would translate 4rd tunnel packet as well as > native IPv6 packet to IPv4 packet and vice verse. Right? If the NAT64 is stateful per session, yes, it does translation at layer 4. NAT64s that are stateless at this layer are however also possible. THis is independent from 4rd. > I don't know > what the CE delegated prefix in NAT64+ looks like. - The delegated prefix is any prefix up to /64 that doesn't match any CE prefix (R-6 of draft-04)) - The source of a CE to NAT64+ packet must have the V octet for NAT64+s to be able to distinguish 4rd packets from other IPv6 packets (def of NAT64+). - The format is then: +-----------------------+-------+---+-----------------+------+ | CE IPv6 prefix | 0 | V | 0 | CNP | +-----------------------+-------+---+-----------------+------+ : =< 64 : >= 0 : 8 : 40 : 16 : Yet, it should be clearer in the draft. Thanks for this (good) question. > Can the native IPv6 > and 4rd shared the same delegated prefix? Yes. (This is the purpose of the V octet) > if Yes, how to distinguish > them? See above. > the figure 6 seems to me it was talking about destination IPv6 > address derivation. Right. > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support > harpinning between 4rd tunnel packet and native IPv6 packet? The only evolution of NAT64 to make it a NAT64+ is its use of tunneling instead of RFC6145 translation, for all IPv6 addresses that have the V octet. (No other behavior needs to be modified.) > Personally, I'd like NAT64+ removed from the draft. It might deserve a > seperate draft. > This way, it would make the draft more understanding > for readers who are new to 4rd-u. The specification has to explain conditions in which a CE can tunnel IPv4 packets although it has no assigned public IPv4 address, even shared. Explaining more what is NAT64+ is IMHO better than explaining less. > 3. Fragments. > The algorithm proposed in R-9, would have applied to generic NAT > generally. Why it is specific to 4rd BR? NATs may have to remember not only destination ports but also source ports. A similar algorithm could however apply to NAT64s, but this is off 4rd scope. > Anyway BR would keep fragment They MAY, but AFAIK don't need to if they use R-9 algorithm. > state somehow and anycase BR facing IPv4 Internet would be impossible. In the CE to BR direction, destinations are full IPv4 addresses so that each fragment can be individually forwarded. Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that no port-based check is needed to ensure that no CE can spoof fragments from another CE. Regards, RD > > Thanks, > washam > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
