Xlate 03 updates and open issues

X. Li, C. Bao, F. Baker2009-11-08

2

Outline

• Terminology• Fragmentation issues • ICMP extensions• The differences from SIIT (RFC2765)

3

Terminology

• Update the terminology – IPv4-translatable address– IPv4-converted address (old names are IPv4-

mapped, IPv4-embedded)

4

Fragmentation handling

• "Don't Fragment", ICMP "too big", and packet fragmentation are in behave-v6v4-xlate– Translating from IPv4 to IPv6 section– Translating from IPv6 to IPv4 section

• Reassembling fragmented packets is discussed in behave-v6v4-xlate-stateful, since it requires state maintenance

5

Translator behavior• What are the differences between xlate and SIIT

(RFC2765) for the MTU and fragmentation handling?– The translator is a normal router

• SIIT does not say this clearly.• Should we say it clearly? Yes.

– Add TCP MSS notes• When implement TCP MSS, it overwrites the other actions.

For the current stateless and stateful translators with MTU=1500 in the end systems, there is no need to modify the TCP MSS, since TCP MSS only counts the payload length.

• Should we allow the translator to adjust TCP MSS?

6

Reduce fragments from IPv4 to IPv6

• From IPv4 to IPv6 when DF=0– SIIT results in fragmented packets (fit in

1280).– Improving this will introduce state– Should we keep this? Yes.

• See Example 1 in appendix

7

In the case of nonstandard implementations

• There is concern IPv6 hosts don't fully implement RFC2460, which says both: – IPv6 minimum MTU is 1280 – IPv6 host might receive ICMP 'too big', via a

6/4 translator, reporting MTU < 1280 – Reference: RFC2460 Section 5.

• Some routers fragment packets even if DF is set to one.

8

Some IPv6 end system does not implement RFC2460

• SIIT: – From IPv4 to IPv6: ICMPv6 (packet too big, the

original advertised MTU+20). – From IPv6 to IPv4: Set DF=1

• Proposed: – From IPv4 to IPv6: ICMPv6 (packet too big, the

original advertised MTU+20). If the advertised MTU in "packet too big" messages is smaller than 1280 bytes, the value put into the translated "packet too big" message is 1280.

– From IPv6 to IPv4: Set DF=0 if the IPv6 packet is smaller than or equal to 1280 and set DF=1 if the IPv6 packet is larger than 1280 (ID copied).

• See Examples 2, 3, 4 in appendix• Should we adopt this proposal?

9

Some routers fragment packets even if DF is set to one

• SIIT:– From IPv6 to IPv4: Set DF=0, MF copied, Offset

copied, ID copied. • Proposed:

– From IPv6 to IPv4: Fragmented packet if MF=0 and Offset=0, set DF=0, otherwise set DF=1, MF copied, Offset copied, ID copied. **

• See Example 5 in appendix• Should we adopt this proposal?

10

ICMP/ICMPv6 extensions options• Related documents

– RFC4884 • Destination Unreachable, ICMP Time Exceeded

and ICMP Parameter Problem– RFC4950

• MPLS– draft-atlas-icmp-unnumbered

• unnumbered• Options

– Pass extensions as opaque bit strings and not translate them.

– Only process the ones defined by RFC4884.– Update document each time there is a new extension.

11

Follow RFC5508 (ICMP NAT) example

• We translate what is in RFC4884 • We don't translate the extensions, i.e. we

pass the extensions as bit strings. – If they need translation, like draft-atlas, this is

likely to cause problems – If they don't need translation, then they work

through translators.

• Should we adopt this proposal?

12

The differences from SIIT (RFC2765)• Redescribing the network model to map the present and projected

usage [I-D.ietf-behave-v6v4-framework]. – Terminology move to framework

• Moving the address format to the address format document [I-D.ietf-behave-address-format], to coordinate with other drafts on the topic.

• Describing both stateful and stateless operation in general.– Move state maintenances related issues to [I-D.ietf-v6v4-xlate-statful]

• Some changes in protocol translation– Transport layer handling– Address mapping for stateless and stateful translation (including

multicast address handling)– Fragmentation handling (to avoid the black hole)– ICMP handling (ICMP extension, translator sending ICMP, arbitrary IPv6

address handling, etc) • Updating references.

13

Appendixes

14

Appendix: Example 1

V4MTU=1500

V6MTU=1500

translationH4 H6

DF=0, PS=1500 (20+1480) Add FG header (gen ID), PS=1280 (40+8+1232)

Add FG header (gen ID), PS=296 (40+8+248)2

15

Appendix: Example 2 (RFC2460)

V4MTU=576

V6MTU=1500

translationH4 H6

PS=1480 (20+1460), set DF=1 PS=1500 (40+1460)

ICMP PTB MTU=576 ICMPv6 PTB MTU=596

PS=1280 (40+8+1232), add FG (MF=0, Offset=0)

PS=1252 (20+1232), set DF=0, cp ID

PS=576 (20+556), set DF=0

PS=576 (20+556), set DF=0

PS=140 (20+120), set DF=0

EndSys

A

B

n4

n4 means using the rules defined in SIIT.If end system implement RFC2460, it should be no problem.

16

Appendix: Example 3 (non-RFC2460)

V4MTU=576

V6MTU=1500

translationH4 H6

PS=1480 (20+1460), set DF=1 PS=1500

ICMP PTB MTU=576 ICMP PTB MTU=596Blackhole

A

n4

n4 means using the rules defined in SIIT.If end system does not implement RFC2460, there will be black hole.

17

Appendix: Example 4 (non-RFC2460)

V4MTU=576

V6MTU=1500

translationH4 H6

PS=1480 (20+1460), set DF=1 PS=1500 (40+1460)

ICMP PTB MTU=576 ICMPv6 PTB MTU=1280

PS=1280 (40+1240) PS=1260 (20+1240), set DF=0, add FG (gen ID)PS=576 (20+556), set DF=0

PS=576 (20+556), set DF=0

PS=148 (20+128), set DF=0

Endsys

A

A

4

4 Workaround.

18

Appendix: Example 5 (strange IPv6 router)

V4MTU=576

V6MTU=1280

translationH4 H6

PS=1500 (40+1460) EndSys

PS=1280 (40+8+1232)

PS=276 (40+8+228)

PS=1252 (20+1232) DF=1

PS=248 (20+228) DF=1

A

4

A

ICMP PTB MTU=576 ICMPv6 PTB MTU=1280

PS=1280 (40+1240)PS=1260 (20+1240), set DF=0, add FG (gen ID)

APS=576 (20+556), set DF=0

PS=576 (20+556), set DF=0

PS=148 (20+128), set DF=0

B Workaround, to avoid ID collision (IPv6 ID 32 bits, while IPv4 ID 16 bits)

19

Appendix: Summary 1 (From IPv4 to IPv6)

IPv4 IPv6

MTU 1500 1500

Fragmentation handling DF=1 Send ICMP (packet too big) to IPv4 source address if the IPv4 packet exceeds 1480 ***

DF=0 Fragment the IPv4 packet so that it fits in 1280 byte IPv6 packet (with fragment header extension, ID copied).

Fragmented packet Fragment header extension (ID copied).

ICMP handling ICMP (packet too big) ICMPv6 (packet too big, the original advertised MTU+20). If the advertised MTU in "packet too big" messages is smaller than 1280 bytes, the value put into the translated "packet too big" message is 1280. *

TCP MSS handling First SYN packet No action.

1

2

3

4

20

Appendix: Summary 2 (From IPv6 to IPv4)

IPv6 IPv4

MTU 1500 1500

Fragmentation handling DF=1 No ICMPv6 action. No fragmentation action. Set DF=0 if the IPv6 packet is smaller than or equal to 1280 and set DF=1 if the IPv6 packet is larger than 1280, ID copied. *

Fragment header extension Fragmented packet if MF=0 and Offset=0, set DF=0, otherwise set DF=1, MF copied, Offset copied, ID copied. **

ICMP handling ICMPv6 (packet too big) ICMP (packet too big, the original advertised MTU-20)

TCP MSS handling First SYN packet No action.

A

B

C

D

21

Appendix: ICMP Error Payload

• If the received ICMP packet contains an ICMP Extension [RFC4884], the translation of the ICMP packet will cause the ICMP packet to change length. When this occurs, the ICMP Extension length attribute MUST be adjusted accordingly (e.g., longer due to the translation from IPv4 to IPv6). If the ICMP Extension exceeds the maximum size of an ICMPv6 message on the outgoing interface, the ICMP extension should be simply truncated.

• For extensions not defined in [RFC4884], the translator passes the extensions as opaque bit strings and those containing IPv4 address literals will not have those addresses translated to IPv6 address literals; this is likely to cause problems with processing of those ICMP extensions.

22

Appendix: ICMPv6 Error Payload

• If the received ICMPv6 packet contains an ICMP Extension [RFC4884], the translation of the ICMPv6 packet will cause the ICMPv6 packet to change length. When this occurs, the ICMPv6 Extension length attribute MUST be adjusted accordingly (e.g., shorter due to the translation from IPv6 to IPv4).

• For extensions not defined in [RFC4884], the translator passes the extensions as opaque bit strings and those containing IPv6 address literals will not have those addresses translated to IPv4 address literals; this is likely to cause problems with processing of those ICMP extensions.