Le 2012-03-19 à 15:30, Maoke a écrit : > > > 2012/3/19 Rémi Després <[email protected]> > > Le 2012-03-19 à 11:38, Maoke a écrit : > ... > >>>> >>>> let me draw an example for that: >>>> >>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>>> router R2 here)--- B > ... > >> 4rd-u isn't concerned with what happens between A and CE. >> There, internal hosts have RFC1918 addresses and external hosts public IPv4 >> addresses. >> >> no problem here for 4rd-u, but RFC6145/6146 work also in the case the >> translator is not located next to the end hosts. then i understand 4rd-u is >> less flexible. > > I don't see the configuration you have in mind. > > > people often insert a router between the home CE and their computers ;-) > sometimes, e.g., because the CE has limited number of ports for connection or > less funtioning.
I still don't see the problem with a NAT44 in the CE. If the CE itself, is behind a transparent CPE, I don't see more what the problem would be. >> >> Anything missing? > ... > >> Both of us know that double translation in general looses some information. >> >> to me, behavior is more important than the acceptable level of information >> loss. > > Not understood. > > > then let's keep our own point for next face-to-face discussion. > > > >> on the other hand, we cannot state 4rd-U doesn't lose any information. > > 4rd options aren't supported (like in MAP-T) > What else do you see as lost e2e? > > > not else end-to-end except the original TTL across the IPv6 cloud. (therefore > i said any 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. >> >> real substantial problem includes the need of "tunnel as virtual link" >> building block in the Internet architecture. > > Keeping it simple, without depending on complex and fussy concepts, remains > IMHO preferable. > > >>>> 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. >> >> yes. but i don't think people keeping part of original packets in ICMP >> message body is trivial. > > If not "trivial" at least quite simple: > > +------------+--------+------------+--------------+ > | IPv6 | ICMPv6 | IPv6 | truncated | > | header, H2 | hdr, C1| header, H1 | payload, P1 | > +------------+--------+------------+--------------+ > || > \/ > +---------+--------+--------+--------------+ > | IPv4 | ICMPv4 | IPv4 | truncated | > | hdr, H2 | hdr, C1| hdr, H3| payload, P2 | > +---------+--------+--------+--------------+ > |<- 8 octet ->| > SRC of H2 is a constant > DST of H2 and H3, and SRC of H2, are copied from fields in H1 > The ICMPv4 checksum is computed from scratch. > > > well, not this case. but the IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing > IPv4 header of original packet). OK. In a 4rd-u domain, middle boxes shouldn't discard packets having ICMPv4 payloads. There is no doubt AFAIK that they can be configured to let go one more protocol (ICMPv4 in this instance). >> 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.) >> >> >> sorry but i couldn't go to Paris due to the company's arrangement. > > > Your presence will be missed. Sorry to learn that. > > > thanks! it is pity that i cannot discuss with you face-to-face this time. > > > > >>> #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. >> >> #2 is not about ICMP about ICMP but about no checksum for IP addresses in IP >> neither in ICMP. i don't think people keeping checksum here or there is >> trivial. > > Not sure to see the issue. > When an ICMPv4 error message is synthesized, its ICMP checksum can easily be > computed, as explained above. > (Always keeping only 8 octets of the original payload, as specified, strictly > limits the computation.) > > > not the ICMP data checksum, but about the integrity of IP header. in IPv4, IP > header has checksum; in IPv6, ICMPv6 checksum includes the pseudo-header. Since the ICMPv4 that is synthesized when an ICMPv6 error message is received is built from scratch (with 8 octets of IPv4 payload copied, but with newly computed checksums), I can't see where there could be a problem. (If you still see one, more details would be needed.) Regards, RD > > regards, > maoke > > > > >>> 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. >> >> IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. > > Sure. > Now, if an ICMPv6 error packet is returned whose partially returned payload > is that of an ICMPv4 message, i.e. with an unknown protocol in IPv6, this > packet can be indifferently discarded or forwarded after DPI without any > negative effect. > (If not discarded here, it will be discarded at 4rd tunnel exit.) > > >> no further concern. > > > Cheers, > RD > > > >> >> >> - maoke >> >> >>> >>> >>> - 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
