Le 2012-03-19 à 06:19, Maoke a écrit : > Remi, > > please see inline. > > 2012/3/16 Rémi Després <[email protected]> > Maoke, > > First: > - My apologies for having not answered this email before receiving a reminder > (it was by mistake lost in a stack of non-urgent things to do). > - Thanks for the clear and detailed analysis. > > More comments in line. > > Le 2012-03-13 à 10:53, Maoke a écrit : > >> Remi, >> >> discussion on R-16 of Sec 4.7: >> >> > R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it >> > MUST synthesize an ICMPv4 error packet [RFC0792]. This packet >> > MUST contain the first 8 octets of the discarded-packet IP >> > payload. >> >> now the ICMPv6 error message contains the payload as the "header-mapped" >> IPv6 PDU of the discarded packet. right? so does 4rd-U CE or BR translates >> this ICMPv6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies >> the checksum adjustment algorithm between ICMPv6 and ICMPv4 here, as the >> RFC6145 does? (for ICMP, the CNP doesn't help) >> >> if it does, you'd better cite RFC6145 here. if it doesn't, please specify. > > dear Remi, you didn't respond this.
AFAIK, I did, but somewhere else (see ** below). >> > If the CE or BR has a global IPv4 address, this >> > address MUST be used as source of this packet. Otherwise, the >> > unspecified address 0.0.0.0 SHOULD be used as this source. >> >> let me draw an example for that: >> >> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; router >> R2 here)--- B >> >> 1. consider ICMPv6 error happens at R1 >> >> original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >> >> CE translates (precisely speaking, "header-maps") it to: >> +------------+----------------------------------------------+ >> | IPv6 | payload | >> | header, H2 | P1 | >> +------------+----------------------------------------------+ >> >> R1 found a error for this IPv6 packet, it generates an ICMPv6 report: >> +------------+--------+-----------+-------------------------+ >> | IPv6 | ICMPv6 | IPv6 | payload (truncated to | >> | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | >> +------------+--------+-----------+-------------------------+ >> \_______________ ___________________/ >> V >> as the ICMPv6 error message body >> >> this message feedbacked to CE, who will translate it to: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >> >> it is clear that 4rd-U address mapping is applied for >> >> H1 -> H2 -> H4 >> >> H3 has the source address of R1 while the destination address as the CE. >> >> then, CE's (or BR's for the case of B --> A) global IPv4 address or 0.0.0.0 >> will be used in H5, right? > > Right. > >> first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address >> represents either a host not yet having gained an IPv4 address on the LOCAL >> network or an application listening on any addresses of a host. > >> packet with 0.0.0.0 might be dropped by any intermediate routers of current >> implementations. > > This address never appears on any IPv4 link. > Intermediate routers being IPv6, there is no problem. > > i doubt there is not a use-case where between A and CE there are some subnet > routers. > > OK? 4rd-u isn't concerned with what happens between A and CE. There, internal hosts have RFC1918 addresses and external hosts public IPv4 addresses. Anything missing? >> > ICMPv6 Type = 1 and Code = 0 (Destination unreachable, No >> > route to destination") MUST be translated into ICMPv4 Type = 3 >> > and Code = 0 (Destination unreachable, Net unreachable). >> > ICMPv6 Type = 1 and Code = 0 (Time exceeded, Hop limit >> > exceeded in transit) MUST be translated into ICMPv4 Type = 11 >> > and Code = 0 (Time exceeded, Time to live exceeded in >> > transit). >> >> for C1 -> C2 translation, i have the following comments: >> >> 1) here 4rd-U uses the CE's global IPv4 address > >> (i think "global" refers to a non-shared one, right?) > > Global address is used as a synonymous of public address. > If somewhere it seems to mean non-shared address, it must be a mistake. > > >> to represent all the error generator inside in the IPv6 domain. this surely >> fits a "tunnel" behavior that attempts to treat the delivery from CE to BR >> as a "link", and therefore the error is responded by the link's end point. >> 2) however, if this is treated as a "tunnel", both ICMPv6 hop-limit exceeded >> and ICMPv6 unreachable node should be translated as ICMPv4 destination >> unreachable (Type = 3) host unreachable (Code = 1), because it should >> indicates the link problem of the tunnel. >> 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a >> typical behavior of path participant rather than a "tunnel". the difference >> of the tunnel and the path participant is: the latter consumes the TTL per >> physical hop. for example, if we set TTL = 32 in H1, tunneling means from A >> to B communication may succeed as long as (A---CE) + (BR---B) doesn't exceed >> 30 hops and CE---BR is well connected; while current 4rd-U means from A to B >> communication may succeed only when total numbers of intermediate routers >> doesn't exceed 31. >> >> this is why typical tunneling solutions initialize the out-header's IPv6 Hop >> Limit to 255. when routing loop happens in the IPv6 domain and Hop Limit is >> consumed out, the link is considered broken. > > I don't see any problem with having, at tunnel exit, the TTL decreased by the > number of traversed routers. > > you don't see it a problem because you reject the common understanding about > "tunnel" as a virtual link, but define the so-called 4rd-tunnel. it has been > admitted by your statement that "4rd tunnel is not any tunnel". Come on! This sentence, which isn't in the draft, cannot be understood off context. The draft is clear about what a 4rd tunnel is, and the point is that, hosts *cannot distinguish* between packets that are natively routed e2e, and those that are tunneled on their way, any number of times and with any tunnel types. > my understanding here is "4rd tunnel" is ACTUALLY another path section of > translation, according to its behavior. if you would say "4rd-U is a > translation solution alternative to RFC6145 providing better transparency in > double-translation environment with some cost and uncertain risk", i would > totally accept without any further argument. Both of us know that double translation in general looses some information. What I wouldn't object to is to rename the Reversible-header-mapping technique as Reversible-header-translation technique. Hope you can accept this as sufficient, so that we can keep this work on real and substantial problems. >> 2. consider ICMPv4 error happens at R2: >> >> R2 sees original IPv4 packet at A, sent to B: >> +---------+----------------------------------------------+ >> | IPv4 | payload | >> | hdr, H1 | P1 | >> +---------+----------------------------------------------+ >> >> R2 has found some error with that packet, issuing an ICMPv4 message and >> sending to A: >> +---------+--------+--------+--------------+ >> | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H6 | hdr, C3| hdr, H1| payload, P3 | >> +---------+--------+--------+--------------+ >> |<- 8 octet ->| >> \__________ __________/ >> V >> as the ICMPv4 error message body >> >> 4rd-U BR translates that to IPv6 version (ICMPv4 as payload of IPv6): >> +------------+--------+--------+--------------+ >> | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+--------+--------------+ >> >> woops, unfortunately, R1 also found something wrong. R1 generates an ICMPv6 >> report, responding back to B: >> +------------+--------+------------+--------+--------+--------------+ >> | IPv6 | ICMPv6 | IPv6 | ICMPv4 | IPv4 | truncated | >> | header, H8 | hdr, C4| header, H7 | hdr, C3| hdr, H1| payload, P3 | >> +------------+--------+------------+--------+--------+--------------+ >> >> BR sees this and makes translation to: >> +---------+--------+---------+--------+--------+------------+ >> | IPv4 | ICMPv4 | IPv4 | ICMPv4 | IPv4 | truncated | >> | hdr, H10| hdr, C5| hdr, H9 | hdr, C3| hdr, H1| payload, P4| >> +---------+--------+---------+--------+--------+------------+ >> |<------- 8 octet ----------->| >> \___________________ __________________/ >> V >> as the ICMPv4 error message body >> >> here an "ICMP of ICMP", which is not allowed in ICMPv4, is generated. here >> 4rd-U can have two options: >> 1) let it be but depends on the IPv4 Internet routers, or host B itself to >> drop the ICMP of ICMP; >> 2) actively check the header in the ICMPv4 message body (H9 above) and >> identify if the protocol of the discard-packet is ICMPv4 too; if so, BR >> drops the packet. >> >> i doubt either is good. anyway, no matter which is used, 4rd-U must deal >> with this issue. (sorry if i missed some text where it has been done.) (**) > The right choice is clearly 2 (RFC792 rightly says: "To avoid the infinite > regress of messages about messages etc., no ICMP messages are sent about ICMP > messages.") > sure 2) is better than 1). however, the remained problem is IPv6 carrying > ICMPv4. i just summarize my concerns here in order the community can judge > the impact: > #1. such kind of packet loses the consistency between the destination address > in the IPv6 header and the source address of original IPv4 header contained > in the ICMP error message. That's getting tricky. Will you be in Paris so that we can discuss with a piece of paper details of what you have in mind? (In the following 3 days, I will be busy otherwise, and will have little or no access to email.) > #2. such kind of packet loses IP header integrity mechanism as neither IPv4's > header checksum nor the ICMPv6's checksum containing pseudo-header is > included. Packets discussed here will never be delivered anyway (ICMP about ICMP). I don't see how any practical concern would appear here. > because it is stated that 4rd-U is "ensuring compatibility with IPv6-only > middle boxes that perform deep-packet-inspection", i here point out at least > #1 checking on ICMP error message being sent to the exact source of original > packet, and #2 checking on IP header integrity by calculating the checksum in > header or pseudo-header cannot rely on the functionality of the middle boxes > in the IPv6-only domain that perform deep-packet-inspection. then 4rd-U CE/BR > MUST consider these issues as well. > > (neither MAP-T nor MAP-E has the similar concern). For MAP-E, of course (compatibility with IPv6-only middle boxes is off scope). For MAP-T, see above. > > > - maoke (**) > It can be made more explicit in the specification. In R-16, after "If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]" we could add "(unless the message concerns a ICMP message, as required by [RFC0792] to avoid ICMP about ICMP)". Thanks, RD > Thanks. > > > Cheers, > RD > > > > >> >> cheers, >> maoke >> >> 2012/3/12 Rémi Després <[email protected]> >> Hello, all, >> >> An updated version of draft-despres-softwire-4rd-u is now available at >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 >> >> Differences with -04 include: >> - DHCPv6 options are now specified >> - various errors and typos are corrected >> - some clarifications are added, following received questions and comments >> - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and >> within CPEs) >> - An editor's note has been added, following a WG-ML discussion, about an >> additional Mapping-rule parameter that might be needed to assign privileged >> ports to to some shared-address CEs. >> - Document layout has been adjusted as a result of other modifications. >> - the authors list has been completed. >> >> Questions and comments are most welcome. >> >> Regards, >> RD >> >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
