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

From: Rémi Després <[email-masked]>
Date: Mon, 12 Mar 2012 15:56:31 +0100

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Mar 2012 17:09:05 -0500

Hi Remi,

My quick comments:
editorial on abstract:
- The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment
   possible via IPv6 networks without maintaining for this per-customer
   states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of
   6rd).
remove: for this.
Better still have a sentence like:
 4rd specifies a protocol mechanism to support Pv4  via a
   service provider's (SP's) IPv6 network without maintaining per-customer
   states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of
   6rd).
- To cope with the IPv4 address shortage, customers can be
   assigned IPv4 addresses with restricted port sets.

It is not customers but it is CPE or CEs, right?

- 4rd-capable customer nodes can exchange packets of their
   IPv4-only applications via stateful NAT64s that are upgraded to
   support 4rd tunnels (in addition to their IP/ICMP translation of
   RFC6145)
replace "of" with "with"

Technical:

I don't understand NAT64+ discussion in this draft (it has been added
in -04). Why do you need it?
In NAT64, IPv6 packet is not created by CE but by the host with the
help of DNS64.Where is DNS64 in your draft, except for a reference to
RFC 6147 which is a bogus reference.
NAT64 helps IPv6 only hosts to communicate with IPv4 only servers over
an IPv6 network. So it has almost nothing to do with 4rd.

One thing you can do is to say that NAT64 could be colocated with 4rd
BR if Pref64 of NAT is chosen to match 4rd prefix. In that case you
need to add support for RFC6145 stateful packet translation as well as
the NAT state in 4rd BRs. Is this what you would like to do?

Maybe I missed something.

Regards,

Behcet

On Mon, Mar 12, 2012 at 9:56 AM, Rémi Després <[email-masked]> wrote:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Tue, 13 Mar 2012 09:53:26 +0000

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.

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

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.

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

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

cheers,
maoke

2012/3/12 Rémi Després <[email-masked]>

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

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Mar 2012 14:49:53 +0100

Hi Behcet,
Please see in line.

>   support 4rd tunnels (in addition to their IP/ICMP translation of

Editorial improvements can be done later, but thanks for your suggestions.
As regards "customer", this word seems to me good enough in an abstract (BTW, the word on which are based CPE and CE acronyms).

> in -04). Why do you need it?

It came as a result of the discussion on 464XLAT in v6ops (=> copy sent to Cameron Byrne).
What is achieved by 464XLAT is AFAIK that, in dual-stack-capable nodes (DS nodes), IPv4-only applications can reach IPv4-only servers via NAT64s.
If a DS node is 4rd-capable, and is in a Domain where it has no public IPv4 address (even shared) but where there is a 4rd-capable NAT64 (called a NAT64+), it does all what it does with 464XLAT, but with an improved IPv4 transparency (DF, ICMPv4, DCCP, UDP Lite ...).

> help of DNS64.

So far, the NAT64 doesn't know how packets are created.
A NAT64+ recognizes IPv6 packets that were created to tunnel IPv4 packets, and takes, for them, advantage of better IPv4 transparency. 

> Where is DNS64 in your draft, except for a reference to

Right, this reference isn't needed. Thanks.
(NAT64s always go with DNS4s in the IPv4/IPv6 framework of RFC6144, but this isn't a 4rd matter.)

> an IPv6 network.

Indeed, but it also helps DS hosts attached to IPv6-only networks to reach IPv4-only servers, e.g. with BIH.
> So it has almost nothing to do with 4rd.

Nothing to do with 4rd... until 4rd includes a way to improve IPv4 transparency of NAT64s for hosts that are DS (upgrading them to NAT64+).

> BR if Pref64 of NAT is chosen to match 4rd prefix.

> In that case you
> the NAT state in 4rd BRs.

Not in 4rd BRs as defined, only in nodes that colocate BRs and NAT64s.

> Is this what you would like to do?
> 

Hope the above is clarifying.

Kind regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Mar 2012 12:05:05 +0100

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 :

> 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)
> 
> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B
> 
> 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.
OK?

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

> R2 has found some error with that packet, issuing an ICMPv4 message and sending to A:
> woops, unfortunately, R1 also found something wrong. R1 generates an ICMPv6 report, responding back to B: 
> 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.")
It can be made more explicit in the specification. Thanks.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Mon, 19 Mar 2012 05:19:23 +0000

Remi,

please see inline.

2012/3/16 Rémi Després <[email-masked]>

> 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).
> dear Remi, you didn't respond this.

> network or an application listening on any addresses of a host.
>
>

i doubt there is not a use-case where between A and CE there are some
subnet routers.

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

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.

> 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

---

From: Washam Fan <[email-masked]>
Date: Mon, 19 Mar 2012 13:57:59 +0800

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

+1.
4rd-U has been considered as a translation mechanism to me (with
better transparency).

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 11:04:57 +0100

> dear Remi, you didn't respond this. 

AFAIK, I did, but somewhere else (see ** below). 

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

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

>> R2 sees original IPv4 packet at A, sent to B:

(**)

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

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.

---

From: Maoke <[email-masked]>
Date: Mon, 19 Mar 2012 10:38:20 +0000

2012/3/19 Rémi Després <[email-masked]>

> There, internal hosts have RFC1918 addresses and external hosts public

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.

> has been admitted by your statement that "4rd tunnel is not any tunnel".
>
>
> Come on!
> 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

to me, behavior is more important than the acceptable level of information
loss. on the other hand, we cannot state 4rd-U doesn't lose any
information.

> What I wouldn't object to is to rename the Reversible-header-mapping
> technique as Reversible-header-translation technique.

real substantial problem includes the need of "tunnel as virtual link"
building block in the Internet architecture.

> contained in the ICMP error message.

yes. but i don't think people keeping part of original packets in ICMP
message body is trivial.

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

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

> For MAP-E, of course (compatibility with IPv6-only middle boxes is off

IPv6 carrying ICMPv6 is able to be deeply inspected by any IPv6 nodes. no
further concern.

- maoke

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

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 15:16:04 +0100

Le 2012-03-19 à 11:38, Maoke a écrit :
...
>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; router R2 here)--- B
...
> 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?
...

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

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

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

> sorry but i couldn't go to Paris due to the company's arrangement. 

Your presence will be missed. Sorry to learn that.

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

> 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

---

From: Maoke <[email-masked]>
Date: Mon, 19 Mar 2012 23:30:02 +0900

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

> loss.

then let's keep our own point for next face-to-face discussion.

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

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

well, not this case. but the
IPv6Header-ICMPv4Header-ICMPv4MsgBody(containing IPv4 header of original
packet).

> Your presence will be missed. Sorry to learn that.

thanks! it is pity that i cannot discuss with you face-to-face this time.

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

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

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 16:03:06 +0100

Le 2012-03-19 à 15:30, Maoke a écrit :

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

> not else end-to-end except the original TTL across the IPv6 cloud. (therefore i said any information. :)
>  
>  
> 
>>  
> 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).

> 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

---

From: Maoke <[email-masked]>
Date: Tue, 20 Mar 2012 00:08:57 +0900

2012/3/20 Rémi Després <[email-masked]>

>>>> 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.)
>>>>
>>>>
>>> (**)
>>>
>>> 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:
>  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
> 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.

well. i mean in the case of 4rd-U IPv6 carrying ICMPv4, integrity of IP
addresses has no checksum to protect. because IPv6 header has no checksum
and ICMPv4 checksum doesn't cover pseudo-header at all. - maoke

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

---

From: Maoke <[email-masked]>
Date: Tue, 20 Mar 2012 00:12:39 +0900

> I still don't see the problem with a NAT44 in the CE.

the topic is about 0.0.0.0 as the source address for the ICMPv6-translated
ICMPv4 message's IP header. if there is a router between the CE and the
host, the packet with 0.0.0.0 will be discarded rather than being
forwarded, according to the common definition of the "unspecified address".

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 16:45:52 +0100

Le 2012-03-19 à 16:08, Maoke a écrit :

> well. i mean in the case of 4rd-U IPv6 carrying ICMPv4, integrity of IP addresses has no checksum to protect. because IPv6 header has no checksum and ICMPv4 checksum doesn't cover pseudo-header at all. - maoke

well, I think the risk of corrupted IPv6 header H1 within the domain can be ignored because L2 checks should be sufficient in this case.

Note that, in case of RFC6145 translation, checking validity of IPv6 addresses implies checksum computation of the complete ICMPv6 message, which can be long.
Do you know BTW if this is actually done in existing implementations?

Since the source of the original IPv4 packet is present in both DST(H2) and SRC(H1), a consistency check can easily be performed for this address. A note about this could be added to the draft.

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 16:49:42 +0100

Le 2012-03-19 à 16:12, Maoke a écrit :

> the topic is about 0.0.0.0 as the source address for the ICMPv6-translated ICMPv4 message's IP header. if there is a router between the CE and the host, the packet with 0.0.0.0 will be discarded rather than being forwarded, according to the common definition of the "unspecified address".

As I already said, 0.0.0.0 never appears on any wire: neither in IPv6, of course, nor in IPv4 where the only in-site IPv4 addresses are RFC1918.
Anything missed?

RD

---

From: Maoke <[email-masked]>
Date: Sun, 25 Mar 2012 10:50:51 +0900

> As I already said, 0.0.0.0 never appears on any wire: neither in IPv6, of
> course, nor in IPv4 where the only in-site IPv4 addresses are RFC1918.
> Anything missed?
>
>
well, not understood at all. Remi, may you please make a numerical example
to explain in detail how the "unspecified IPv4 address" is used in
4rd-u/NAT64+? thanks in advance!

- maoke

---

From: Rémi Després <[email-masked]>
Date: Sun, 25 Mar 2012 09:18:31 +0200

Le 2012-03-25 à 03:50, Maoke a écrit :

> well, not understood at all. Remi, may you please make a numerical example to explain in detail how the "unspecified IPv4 address" is used in 4rd-u/NAT64+? thanks in advance!

OK, there is a point for ICMPv4 whose source is not a public IPv4 address. 
I agree that using 0../0 in this case creates a problem because some routers or FWs may discard packets having this address as source.
This should be avoided by coming back to what there was in draft-03, i.e. 192.70.192.254 
Thanks.
 
Regards,
RD