Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

[Rémi Després <[e-mail]>]

Maoke,
Thanks for the detailed question.
Clarification below.


2012-03-09 12:04, Maoke  :
> 2012/3/9 Rémi Després <[e-mail]>
> Thanks Maoke for the opportunity to clarify some of the points below.
> 
> 
> 2012-03-09  03:14, Maoke:
> 
>> hi Remi,
>> 
>> sorry but i follow this late. something not clear to me, according to our earlier discussions.
>> 
>> 2012/3/8 Rémi Després <[e-mail]>
>> 
>> Le 2012-03-08 à 03:47, Washam Fan a écrit :
>> 
>> > Hi Remi,
>> >
>> >>>>> Secondly, -04 added NAT64+ parts.
>> >>>>> If I understood correctly, there are no additional requirements for NAT64
>> >>>>> boxes.
>> >>>>
>> >>>> Well, NAT64 boxes remain what they are.
>> >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 although it
>> >>>> has a dual stack.
>> >>>>
>> >>>> But the advantage of 4rd tunneling over RFC6145 double translation is better
>> >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that may
>> >>>> use the TCP checksum algorithms)
>> 
>> to clarify my understanding:
>> 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the DF=1/MF=1 cases
>> 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message directly as IPv6 payload is a wise idea. lack of address consistency ensurance mechanism (i.e. no header checksum in IPv6 header no pseudo-header checksum in ICMPv4 message)
> 
> The 4rd ICMPv4 error message has as only purpose to be delivered to a 4rd-aware node. There, it will be treated as an ICMPv4 error.
> It is assumed that no DPI in some middle box will need to interpret ICMPv4 error messages. 
> 
>> 3. for the "future protocols", i remember our earlier discussion concluded that CNP can free the code change with ALREADY KNOWN tcp-checksumed protocols. am i wrong here? 
> 
> I think you are. As the 4rd-u-04 says (sec 4.4):
> "NOTE: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol.  Today, such protocols are UDP [RFC0768], TCP [RFC0793], UDP-Lite [RFC3828], and DCCP [RFC5595].  Should new ones be specified, BRs will support them without needing an update."
>                                                                                                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> exactly here it is the point of disagreement. here the "update" refers to implementation, right? then what is the BR's logic? 

> 
> A. if (L4_Proto in LIST{UDP, TCP, UDP-Lite, DCCP}) {
>       calculate IPv6 address for dst, taking the port from L4_proto.header; 
>       /* do nothing with checksum, CNP applied for the LIST */
>    } else {
>       discard;
>    }

No. R-7 (3) isn't ambiguous about this.


> B. if (1) {
>       calculate MAP IPv6 address for dst, supposing dst port is always there;
>       /* do nothing with checksum suppose CNP applied to all protocols */
>    }

Yes, as specified in R-7 (3).

As a matter of fact, it doesn't "suppose dst port is always there". 
It just takes bits that are the right ones if dst port (or ICMPv4 ID) is present, unless a source has, by mistake, sent a port-less packet to a shared IPv4 address.
What happens in this mistake case is detailed below.  


> if you refer to logic B, the "BR will support them without needing an update" is true.

Right.

> however, the risk is should new ones specified but not having the tcp-like layout or the tcp-checksum may fail to become a valid IPv6 packet and (because of the layout difference) it is possible that the destination IPv6 address is wrong. 

If a source sends to a shared IPv4 address with a port-less protocol, it will receive a  "destination unreachable" ICMPv4 packet.
Its code will be either "network unreachable", because no CE had the derived IPv6 address (sec. 4.7), or "protocol unreachable", because the reached CE NAT44 cannot process this port-less protocol.
The usual error-signalling mechanism works as it has to.

> if you refer to logic A, the BR must be updated whenever any new protocol is added to the LIST. this is the same as RFC6145. btw, RFC6145's logic, when applied with MAP, is:
> A'. if (Payload_Proto in LIST{UDP, TCP, ICMP}) {
>       calculate IPv6 address for dst, taking the port (or equivalent field when ICMP) from Payload_Proto.header; 
>       recalculate the checksum in Payload_Proto.header;
>    } else {
>       discard;
>    }
> 
> 
> both A and A' has no risk as B has.

See above why B has no operational risk.

Thanks,
RD


 
>  
> 
> 
> 
>> >>>> For an ISP to extend this advantage to its stateful NAT64, it need to be 4rd
>> >>>> aware (become a NAT64+).
>> >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a V
>> >>>> octet instead of a "u" octet), use the 4rd header mapping instead of RFC6145
>> >>>> translation.
>> 
>> questions: 1. NAT64+ here refers to stateful case only, right?
> 
>> 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision between 4rd-U pseudo-encapsulation (let me use this term because  i argue it does not conform to the behavior of encapsulation) and NAT64 translation? (as we have neither V nor U in the IPv4 addresses).
> 
> a) Note that there is no claim that 4rd-u would be an encapsulation solution (it isn't!). What is claimed is that it is a transparent-tunnel solution (same IPv4 packet received by destinations as sent by sources, except for TTL which progress, and for ECNs that may be changed if congestion is met between source and destination). 
> 
> yes. TTL is progressing as if it were in translation. ECN is another topic: it changes even in the encapsulation. 
>  
> 
> b) In draft -04, R-7 (8) says:
> "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 address; append the CNP.
> <----------- Rule IPv6 prefix --------->:
> +-------------------------------+---+---+-------------+------+
> |      NAT64+ IPv6 prefix       |"u"| 0 | IPv4 address|  CNP |
> +-------------------------------+---+---+-------------+------+
> :               64              : 8 : 8 :      32     :  16  :
> 
>                                        Figure 6              "
> what do you mean with the unspecified IPv4 address*es*? isn't it only the 0.0.0.0, or you mean 0.0.0.0/0 excluding the mapped-in-rule block?  
> 
> reading your example in 5.1, i understand your point: the above picture describes the mapping for the source address if the packet is sent to the IPv6 world through BR but without the inverse-header-mapping. in this case the U-octet is applied and the CE-delegated prefix plays also the role of NAT64+ IPv6 prefix. and the NAT64+ translation happens at CE. right? if i'm right, it is clear. 
> 
> but i haven't seen the necessity of defining the V-octet here. with the V, BR seeing the V does the header mapping while seeing the U does nothing but only the regular routing. without the V, BR seeing the CE-delegated /64 does the header mapping while seeing another prefix (no matter how long the length is) does nothing but only the regular routing. 
> 
> the V-attached stuff in fact makes another, more-specific prefix under the delegated prefix of a CE. 
>> >>>
>> >>> I perfer to leave NAT64 out of scope.
>> >>
>> >> NAT64 as is remains out of scope.
>> >> What is in scope is only the possibility to improve IPv4 transparency of NAT64 nodes by using transparent tunneling, instead of double translation, when reached by 4rd CEs (making them NAT64+ nodes).
>> >
>> > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a
>> > new term NAT64+ invented?
>> 
>> 
>> NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 needs to be upgraded to replace RFC5145 translation by header mapping when IPv6 addresses it deals with are 4rd addresses (have the V octet).
> 
> confused. how does NAT64+ happens at BR? without the V octet, NAT64 needs not to be upgraded at all. 
>> 
>> 
>> >
>> >> This new capability, introduced in -04, is derived from the 464XLAT proposal.
>> >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks can communicate via NAT64s, but IPv4 transparency has limitations which can be eliminated by upgrading NAT64s to NAT64+ status (a backward compatible evolution).
>> >>
>> >
>> > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is?
>> 
>> To take advantage, for customers that are 4rd capable, of better IPv4 transparency than with double translation, the NAT64 MUST be upgraded.
> 
> 
> Remi didn't answer this question of Washam. 4rd-U keeps only stateful NAT64 as it is at CE, to my understanding. 
>  
>> 
>> may i add that it (4rd-U) provides better IPv4 transparency than double translation but less simplicity in the term of layering architecture than encapsulation? (here i avoid sticking things on my understanding to "transparency"). personally i don't think transparency is the most important reason that generally operators prefer encapsulation rather than translation. simplicity and clear concept in architecture is the reason. no matter how much we keep IPv4 information unchanged across the IPv6 domain, as long as the IPv4 header is destroyed, it is a solution of "translation" rather than of "encapsulation". 
> 
> Different view here.
> a) Ole had a nice slide in the interim meeting about how double translation tends to break transparency. I use "reversible header mapping" which I find intuitive, or just "header mapping", but "reversible header translation" could be OK. 
>  A key difference, is that payloads are transparently tunneled in 4rd while they are processed, with dependence of upper layer protocols in double translation. This is AFAIK an important difference. (To take an example, RFC6145 requires to discard UDP-lite packets (RFC3828) while they are tunneled with 4rd)
> 
> where is it stated in RFC6145 that it requires to DISCARD UDP-lite packets? 
>  
> 
> b) As said in Sec 1 of draft -04:
>  " While IPv6 headers are too long to be mapped into IPv4 headers, so that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4 headers can be reversibly mapped into IPv6 headers so that 4rd tunnel packets can be designed to be valid IPv6 packets, thus ensuring compatibility with IPv6-only middle boxes that perform deep-packet-inspection."
>  I see no real complexity in noting that IPv4 headers are small enough to be reversibly mapped in IPv6 headers.
> 
> our terminologies are biased. i emphasize the simplicity is in the term of architecture. encapsulation is a widely used concept in the networking, making one protocol as an underlay of another. we may have a packet with all the Ethernet-IP-TCP-HTTP header fields in a PPP framework plus but re-ordered and re-organized, into, e.g., a super L2-U. it is surely a reversible header mapping but we can't say that of either encapsulation or the (narrow-sense) tunneling. this is my point. from the operator's view, once it is not the simple layered encapsulation, i cannot see it as a substitute for the encapsulation, but see it as a substitute of other translations, if i see this is a more gentle translation than others and this gentleness costs little. 
>  
>  Of course this still requires careful technical verification, but once done, it's done once and for all. 
> 
>> i don't incline to use the term "tunneling" since tunnel could have a variety of forms, among which encapsulation is one but not the only one. 
> 
> Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation tunnels.
> 
> well, in general sense "tunnel" means a source route essentially (RFC1241 made a very good summary about variety of tunnels). to such extent, RFC6145 makes *translation tunnels* (in general sense of the term "source route"). but we never call it like that, because, when most people are talking about "tunnel" today, we refers to the narrow sense "tunnel", which means the encapsulation. it is fine that 4rd-U call itself as a tunnel solution but it should be pointed out that this is a tunnel in the general sense. 
> 
> therefore i emphasize that, maybe too academic, the counterpart of translation is encapsulation but not the "tunneling". in the architecture, we have either the building block of making an underlay protocol as a virtual link or the building block of making another protocol as a participant in the path of end-to-end delivery. although you argued this is *ONLY* the understanding of some diffserv guys, i don't think this understanding is not generic. 
> 
> for the simplicity in operation, we often think in such a way: if we would like to hide the underlay and make a protocol as an underlay or we would like to expose the things out. both have their use cases. if 4rd-U is said it fills some important gaps between the two, it would be great. if 4rd-U is said it replaces the both, i doubt it can. once we want to make a stuff having advantage of this and that, we often make out a stuff also having disadvantage of both. for me, i prefer if 4rd-U is moderately defined with specific use-case and fully description on its pros/cons, features/limitations, approaches/tradeoffs. 
> 
> cheers,
> maoke
>  
> 
> 
> Cheers,
> RD
> 
> 
> 
> 
>> 
>> cheers,
>> maoke
>>  
>> Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, or dual-stack hosts supporting BIH of RFC6535): they can continue to use the NAT64+ as an ordinary NAT64.
>> 
>> Regards,
>> RD
>> 
>> >
>> > Thanks,
>> > washam
>> >>> Such transparency could be achieved by whther to add fragmentation header.
>> >>> Anyway, let's hear some comments from the group
>> >>
>> >> OK
>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> 
>