Le 2012-02-16 à 12:19, Maoke a écrit : > 2012/2/16 Rémi Després <[email protected]> > > 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? > > agree. for this point, we'd prefer to propose an update to RFC6145 in order > to clear the uncertainty, if the authors have not other concern we haven't > noticed.
Seems good to me. However, a specification change doesn't ensure that all devices support the change. A problem therefore remains. > > > >> 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. > > good. thanks! > > >> >> 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. > > it confuses me. > if there is no new protocol, where we have the talking topic on the *change* > of BR? neither MAP nor 4rd-U needs change if there is no new protocol. Clear. > if there is new protocol in consideration, how do you assert such a new > protocol surely not work for shared IPv4 addresses unless it is a > "traditional" one? Yes, I do suggest that a transition tool such as MAP/4rd shouldn't be modified to support a new protocol that would have been be specified with consciousness that it is difficult to support in NAT44s. > do you mean non-traditional protocol is nonsense and we have no obligation to > consider? A nonsense, by no means! Defining new protocols, even with non-TCP checksum, can make a lot of sense, but only in the context of IPv6. > or do you mean, new protocol working with shared IPv4 addresses must be > traditional? My point is that any new protocol that should work for hosts having IPv4 shared addresses SHOULD use the TCP-like checksum, yes. (I use SHOULD instead of MUST because we talk about the future, which is uncertain by nature.) >> 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). > > i think i focuses on the point that the "BR needs no change ...". > > > - 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. > > MAP-T has been in running code and it is not complicated to remove the > uncertainty with changing the OPTIONAL to a definite word, unless there is > something we haven't noticed. This point has no relationship with the fact that checksum neutrality provides BR support of all L4 protocols using TCP-like checksum. >>> 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. > > right, here the "single-link traversal" causes TTL decreases more than 1. > well, you removed this self-contradictory. > > 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." Note that this part of the sentence no longer appears in the revised R-4 > > misunderstanding! > please note that ECN being propagated from intermediate IPv6 to IPv4 is > correct even for the mode of encapsulation! Exactly, where it it applies in 4rd-U (no Tunnel traffic class parameter) it does it for both -H AND -E. > because congestion is a link-wise behavior. RFC3168 Sec 9 discussed this and > its succeeding updates RFC6040 takes a huge effort in order to achieve > compatibility among different processing proposals regarding the potential > inconsistency between the outer header's ECN and inner header's ECN. the > basic operation is: tunnel entry point should copy ECN from inner to outer > header while tunnel exit should copy ECN from outer to inner. Right > > - 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". > > "belongs to" or not is only a text gaming. i focus on the behavior: > you stated it is "as encapsulation" and therefore i argue its behavior is not > encapsulation behavior at all. 4rd-H IS NOT "encapsulation" (not more than it is "double translation"). The only claim is that it is, end-to end, as transparent to IPv4 packets as encapsulation. > > 2. MAP-E has the same need. Otherwise unreachable CEs couldn't be signaled to > IPv4 sources, right? > > MAP-E applying any existing encapsulation standard such as RFC2473 or GRE as > the packet processing method surely has been ready for that. the same need > has been satisfied without need to define again. it could be emphasize the > RFC2473's ICMPv6-to-ICMPv4 processing is consistent with the semantics of > "virtual link" which the encapsulation contributes to the Internet > architecture. I didn't see this ICMP translation in the BR behavior of the MAP-E draft sec. 5.2, but it certainly can be added. In any case, this doesn't make 4rd-U less end-to-end transparent to IPv4 than encapsulation. > The point remains that 4rd-U is "as transparent to IPv4 as MAP-E". > > narrow sense transparency, no problem in wording. but i suppose people are > concerning the behavior rather than the wording itself. > > 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). > > encapsulation makes underlay as a link-layer, and certainly the TTL only > decreases by 1 if no trouble. decreasing as the same in the underlay network > is the behavior of translation. > it exposes the details of the underlay and therefore not transparent as > encapsulation. Different view (IMHO, this statement is just playing with words) Regards, RD > > best, > maoke > > > > 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
