1 / 9

Conex IPv6 format

Conex IPv6 format. Suresh Krishnan Mirja Kuehlewind . Requirements for marking IPv6 packets. R1: The mechanism needs to be visible to all nodes on the path R2: The mechanism needs to be able to traverse nodes that do not understand the markings

ivy
Download Presentation

Conex IPv6 format

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. Conex IPv6 format Suresh Krishnan Mirja Kuehlewind

  2. Requirements for marking IPv6 packets • R1: The mechanism needs to be visible to all nodes on the path • R2: The mechanism needs to be able to traverse nodes that do not understand the markings • R3: The presence of the marking mechanism should not significantly alter the processing of the packet

  3. Candidate solutions • Extension headers • Hop-by-Hop Options • Bits in the IPv6 header

  4. Extension Headers • The base IPv6 standard [RFC2460] defines extension headers • An expansion mechanism to carry optional internet layer information. • Extension headers, with the exception of the hop-by-hop options header, are not usually processed on intermediate nodes. • This is not set in stone, but is hard to change • Unknown extension headers cause the packet to be dropped

  5. Hop-by-Hop Options • The base IPv6 standard [RFC2460] defines hop-by-hop options • These options are processed by every node on the path • The options have variable semantics based on the 3 MSB of the option code. • The state of the bits controls • Behavior of nodes to either ignore unknown options or drop packets containing them. • ICMPv6 error message sending behavior • Mutability of the options en-route • Result in the packet being punted to the “Slow path” instead of being accorded regular forwarding behavior (“Fast Path”) • This is implementation specific, but true of most common router implementations

  6. Bits in the IPv6 header • The IPv6 header has NO FREE BITS • There is no magical way to make more bits appear  BUT • The IPv6 flow label field (RFC3697) has not been widely used • There are some initiatives to redefine the use of the flow label for other purposes (e.g. Load balancing, nonce) • It may be possible to save a few bits from the flow label for alternate purposes to end up with a shorter flow label • A draft exists requesting 4 bits for future use but has not received a warm welcome (I am being charitable here )

  7. Summary

  8. Items for discussion • How is ECN done for IPv6? Why can’t we do the same? • The ECN field is defined identically for IPv4 and IPv6 • Uses bits from the traffic class field (2 bits for ECN) • No spare bits in the Traffic Class field either (the other 6 bits are used for DSCP) • How many bits are potentially needed? • Conex abstract mechanisms describes a need for 5 code points. • This translates to at least 3 bits needed • Is there a need for more? • Higher the number of bits needed, the higher the resistance to obtain them

More Related