Re: [Softwires] Draft 4rd-u-05 is available

[Rémi Després <[e-mail]>]

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.

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

> 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?

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


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


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


>> 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 <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>> 
>> 
>> 
> 
>