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. > > > > >> 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). > > > > 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. 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
