Maoke, Good to see that at least one who has read the 4rd-u draft still considers that technical considerations are worth working on. Thanks.
IMHO, you did a great job to structure this (useful) discussion. Here are quick comments/suggestions/corrections I propose: 4.1. (M2) Rather than "simplification of L4 protocol treatment" the motivation is "Full IPv4 transparency, with never modified payloads and IPv4 fragmentation semantics" 4.1. (M4) a motivation to be added: "No constraint on subnet-ID assignments in customer sites" 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as ensured as in MAP-E" instead of "4rd-U argues it should be supported no matter how minor it is observed in practice". 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they prefer, concerning DiffServ architecture, provided users cannot make the difference" instead of "4rd-U argues ToS should be kept unchanged when the packet traverses the IPv6 domain, except the ECN bits". 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet validity of IPv4 tunneled packets, for all present and future protocols that have ports as the same place as TCP and the same checksum algorithm, without being concerned with where these protocols have their checksum fields" instead of "it also argues checksum validity should be ensured through address in order to simplify L4 processing" 4.2. (O6)- to be added "UDP null checksums: [RFC6145] can be configured either to drop all IPv4 packets having null checksums, or drop only those that are fragmented. 4rd-u argues that this lack of IPv4 transparency should be avoided." 4.2. (O7)- to be added "Free assignment of subnet IDs: subnet IDs that follow customer-site prefixes in native IPv6 addresses are so far freely chosen for each customer site. 4rd-u argues that this freedom should not be lost, despite the need to distinguish IPv4-originated packets from native IPv6 packets at customer-site entrances. 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6), and (07), should IMHO be considered in scope (if a new version is issued). 5.1 Impact - "Since [RFC6145] is already such that middle boxes see unfragmented IPv6 packets having fragment headers, there is no new impact" instead of "always seeing fragment header is strange to middle boxes in the IPv6 domain. The system administrators of any middle box SHOULD be informed on the deployment of 4rd-U". 5.2 Impact - a. This, not being a concern between 4rd-u nodes, isn't needed here. 5.2 Impact - b. Not understood. 5.3 4rd-u semantics - (1) you make a VALUABLE POINT. "hop limit exceeded" should be translated to "host unreachable" as in RFC2473 (sorry for this (small) bug in 4rd-u-06). Then, the the semantics is equivalent to that of RFC2473. The only practical difference is that, if the received TTL is < 128, routing problems are detected after 127 hops within the ISP domain instead of 255 (negligible IMHO provided it is known). 5.3 Impact d. - Unless you can elaborate what you would fear, I think there is no such impact. 5.4 Impact a. - Add ", instead of protocol 4 (IPv4) in RFC2473" after "IPv6 domain MUST set all filters in middle boxes to pass protocol 1 (ICMP) as IPv6 payload in order to support 4rd-U functionality". 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But this integrity can be ensured at tunnel exit by checking that CNPs do preserve checksum neutrality. This can be clarified by a complement in the 4rd-u security section. 6. The statement that "double translation is also a sort of tunneling in general sense" is IMHO confusing in view of its lack of IPv4 end-to-end transparency. The statement that "It needs further investigation to ensure if 4rd-U is qualified to be called as a tunnel in the narrow sense" expresses a doubt without substance to justify it. 4rd-U only claims that IPv4 packets traverse ISP domains transparently (unless they have IPv4 options in which case the domain signals it doesn't support them). 7. Similar to encapsulation - Add "UPP datagrams with null checksum are tunneled". - Delete "Middle boxes in the tunnel are unable to check if ICMPv4 message is sent to correct destination". (There is no beed for this since tunnel-exit endpoints can ensure correct destinations - see 5.4 impact c.) 7. Similar to double translation - Add "Middle boxes can treat tunneled IPv4 packets as valid IPv6 packets for all protocols that have port positions and checksum algorithm of TCP". - What you mean by "without protocol layering, position of IPv4 fields are changed" is unclear to me. To be deleted or explained. - "IPv4 options are not supported" instead of "IPv4 options are removed" 7. Never seen ... - Add "Residual IPv4 service can be supported in sites that use subnet ID = 0". - Fragmented packets addressed to shared-address customer sites can be tunneled without packet reassembly at domain entry." Kind regards, RD Le 2012-04-10 à 11:53, Maoke a écrit : > hi all, > > i made an internet-draft discussing the semantics issue of 4rd-U. comments, > recommendations, technical discussions are welcome. > > http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00 > > thanks and regards, > maoke > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: 2012/4/10 > Subject: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt > To: [email protected] > > > A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been > successfully submitted by Maoke Chen and posted to the IETF repository. > > Filename: draft-chen-softwire-4rd-u-comment > Revision: 00 > Title: A Commentary on 4rd-U Architecture and Semantics > Creation date: 2012-04-10 > WG ID: Individual Submission > Number of pages: 19 > > Abstract: > 4rd-U is proposed as an effort of unifying encapsulation and double > translation solutions for the softwire of IPv4 over IPv6 domain. > This attempt introduces new behaviors in the Internet transition > architecture as well as semantics other than that of well-known > Internet protocols. This documents provides a commentary on the > semantic changes and their impacts. > > > > > The IETF Secretariat > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
