Le 2012-02-16 à 03:34, Maoke a écrit
> 2012/2/15 Rémi Després <[email protected]>
> 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.
>
>> ...
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
