Re: [Softwires] Checksum neutrality and L4-protocol independence

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

Le 2012-02-16 à 03:34, Maoke a écrit 
> 2012/2/15 Rémi Després <[e-mail]>
> 2012-02-15 à 03:15, Maoke a écrit :
>  
>> "protocol unknown" should be detected and discarded at both CE and BR in their major module instead of the NAT44 part.
> 
> I don't think so:
> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't exclude any protocol in packets sent to this CE.
> - If a CE has a shared address, it needs a NAT that the CE informs it the restricted port set. This NAT already has all what is needed to refuse protocols it doesn't understand. 
> 
> what if my NAT has understood XXXP but your CE hasn't? to my understanding, CE only informs the restricted port set regardless of the protocol. 

2 cases:
- If the new protocol has ports at their usual place, and has TCP-like checksum, no problem. "Your CE", as you call it, does forward packets of the new protocol. 
- In other cases, any CE or BR would need needs an update to work, and incompatibilities cold result. 
 

...
> 
>> A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,
> 
> Not SCTP today, for sure.
> Also, as I think you know, there is uncertainty concerning DCCP because RFC6145 sec 4.5 says:
> "Other transport protocols (e.g., DCCP) are OPTIONAL to support".
> 
> it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for the operation domain, it is not a problem for double translation. if it is OPTIONAL per device, the uncertainty is a problem where src-translator makes DCCP checksum rewrite but dst-translator doesn't. (inverse case, where src translator doesn't make but dst do, is not a problem though.) 

Optional "for the operation domain" would work only if there would be means to inform CEs of the choice made for the domain.
Such means don't exist, right?


> ok, i think we do understand your point but please check. you mean: if addresses are checksum-neutral, we don't need to have a list of supported protocol in BR and just let it pass any protocol with the assumption that it is TCP-layouted/checksumed. if the "any protocol" happens to really have TCP-layout and TCP-checksum, then things are happy and the addresses have ensured the checksum validity even without L4 rewrite. if the "any protocol", unfortunately, happens to have another layout and/or another checksum, then BR also treat it as it were TCP-layouted/checksumed but let it fail at the end host or CE. right?

Yes.
We are in sync on this point.

> 
> here it is what i said R-22 (3) in 4rd-U is dangerous. it says: 
> 
>    + If the packet Protocol is not ICMP, bits 0-15 for an
>    IPv4 source address, and bits 16-31 for a destination
>    address.
> 
> well doesn't it mean: even if the protocol has another layout, R-22 (3)'s BR prefer to ignore the fact, making messy mapped addresses with blindly assuming the protocol follows the TCP-layout!? (there is no NAT44 before BR to ensure the "unknown" protocol has been dropped.) i would further point out that, the messy mapped destination address may navigate your packet in a wrong direction towards a wrong CE where even the "fail at end" may fail.

Still a misunderstanding here.
No new protocol will work for shared IPv4 addresses, be it with MAP or 4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their usual place, and a TCP-like checksum somewhere).
A NAT44 that is coupled with a CE MUST remain operational ONLY for "traditional" protocols.

(Future protocols, if not "traditional", will need IPv6 to work safely, including with shared-IPv4-address CEs.



> therefore i do agree Ole's argument. because we think any protocol should be certainly supported, or certainly reported as not-supported, rather than blindly trying a seemingly "universal" logic. 

1.
I don't know which "Ole's argument" you agree to (making your own points directly would be clearer). 
- In particular, Ole wrote "any A+P solution requires support for L4 protocols to extract ports. L4 checksum rewrite, as well as port extraction will have to be supported for all new L4 protocols."
- The fact is that 4rd-U, because of checksum neutrality, doesn't have to support L4 checksum rewrite. Yet, it is an A+P solution that has no identified operational problem.

2.
4rd-U "certainly" supports All "traditional" protocols, an Echo requests in identified conditions,  and nothing else.
MAP-T is AFAIK uncertain for DCCP.


>> btw, regarding the below "new standard for a new problem", i'd like to emphasize it is not a new problem as RFC6052 has discussed it. it is an incorrect understanding to think RFC6052/RFC6145 is designed only for single translation. since the very beginning of the stateless address mapping/translation design, the single and double translations have being considered. 
> 
> I have no intention to negate anything about what designers of RFC6052/6145 considered (I wasn't there ;-)).
> 
> The problem which IS NEW is how to design a stateless v4/v6 solution that:
> - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction or doubt
> 
> NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2 points: 
> 
> 1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. this is not a behavior of encapsulation but a behavior of translation. 

1.
Well, there remains an inconsistency that I didn't see in the 4rd-U draft(!): 
- "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel traversal is treated in IPv4 as a single-link traversal. Without it, Explicit Congestion Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations, and IPv4 Time to live values progress with the number of traversed IPv6 links."
- Table 2 has:
+---------------------+-----------------------------------+
| IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
+---------------------+-----------------------------------+
                    ...
| Time to live        | Hop limit                         |
                    ...
+---------------------+-----------------------------------+

 Correction should be:
"R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit Congestion Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations."
Thanks for the opportunity to notice this inconsistency.

2.
IPv4 time-to-live of an IPv4 may thus progress by more than one during domain traversal, right, but this isn't a breach to IPv4 end-to-end transparency (the TTL is THE field that always evolve during network traversal). 


> 2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please note that RFC6145 Sec 5.2 is a typical behavior of translation rather than encapsulation. for the encapsulation, the semantics of ICMPv6 message processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but never cites it in the main text). 

1. How an IPv6-generated ICMP message is translated into an IPMPv4 message, doesn't belong to "IPv4 transparency".
2. MAP-E has the same need. Otherwise unreachable CEs couldn't be signaled to IPv4 sources, right?

The point remains that 4rd-U is "as transparent to IPv4 as MAP-E". 
This is AFAIK a simple and important fact (it was designed for that). 


> if we say some fields are transparent, that's ok.

> but if we are talking about the IP as a whole, TRANSPARENCY implies not only the consistency of packet header fields but also the behavior of hiding details of the carrying underlay infrastructure.

Agreed.
(But with due understanding of the exception of time-to-live: it always decreases end to end, and more or less depending on peculiarities of traversed infrastructures). 


Regards,
RD



>  
> 
> best,
> maoke
>  
> - yet works with IPv6-only port-based ACLs and IPv6 Web caches.
> In my understanding, 4rd-H is indeed such a solution (and is the only one on the table).
>  
> 
> Regards,
> RD
> 
> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a different subject which deserves a discussion thread with another title.
> 
>> ...
>