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