1 / 22

Xlate 03 updates and open issues

Xlate 03 updates and open issues. X. Li, C. Bao, F. Baker 2009-11-08. Outline. Terminology Fragmentation issues ICMP extensions The differences from SIIT (RFC2765). Terminology. Update the terminology IPv4-translatable address

morna
Download Presentation

Xlate 03 updates and open issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Xlate 03 updates and open issues X. Li, C. Bao, F. Baker 2009-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. V4 MTU=1500 V6 MTU=1500 H4 DF=0, PS=1500 (20+1480) translation H6 Add FG header (gen ID), PS=1280 (40+8+1232) Add FG header (gen ID), PS=296 (40+8+248) 2 Appendix: Example 1

  15. V4 MTU=576 V6 MTU=1500 H4 translation H6 PS=1480 (20+1460), set DF=1 PS=1500 (40+1460) ICMP PTB MTU=576 ICMPv6 PTB MTU=596 End Sys PS=576 (20+556), set DF=0 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=140 (20+120), set DF=0 n4 means using the rules defined in SIIT. If end system implement RFC2460, it should be no problem. A B n4 Appendix: Example 2 (RFC2460)

  16. V4 MTU=576 V6 MTU=1500 H4 PS=1480 (20+1460), set DF=1 translation PS=1500 H6 Black hole ICMP PTB MTU=576 ICMP PTB MTU=596 n4 means using the rules defined in SIIT. If end system does not implement RFC2460, there will be black hole. A n4 Appendix: Example 3 (non-RFC2460)

  17. V4 MTU=576 V6 MTU=1500 H4 translation H6 PS=1480 (20+1460), set DF=1 PS=1500 (40+1460) ICMP PTB MTU=576 ICMPv6 PTB MTU=1280 End sys PS=576 (20+556), set DF=0 PS=1260 (20+1240), set DF=0, add FG (gen ID) PS=1280 (40+1240) PS=576 (20+556), set DF=0 PS=148 (20+128), set DF=0 4 Workaround. A A 4 Appendix: Example 4 (non-RFC2460)

  18. V4 MTU=576 V6 MTU=1280 H4 translation H6 PS=1252 (20+1232) DF=1 PS=1280 (40+8+1232) PS=1500 (40+1460) End Sys PS=248 (20+228) DF=1 PS=276 (40+8+228) ICMPv6 PTB MTU=1280 ICMP PTB MTU=576 PS=576 (20+556), set DF=0 PS=1260 (20+1240), set DF=0, add FG (gen ID) PS=1280 (40+1240) PS=576 (20+556), set DF=0 PS=148 (20+128), set DF=0 4 A B Workaround, to avoid ID collision (IPv6 ID 32 bits, while IPv4 ID 16 bits) A A Appendix: Example 5 (strange IPv6 router)

  19. 1 2 3 4 Appendix: Summary 1 (From IPv4 to IPv6)

  20. A B C D Appendix: Summary 2 (From IPv6 to IPv4)

  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.

More Related