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. > > > 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? > > > > 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". 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. > > > > 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. #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. 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). - maoke > It can be made more explicit in the specification. 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
