Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 Hop-by-Hop & Destination Option #56

Open
wants to merge 9 commits into
base: master
from

Conversation

@rsivakolundu
Copy link
Contributor

commented Oct 3, 2018

IPv6 Hop-by-Hop and Destination Option for INT Header and INT Metadata transport

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

Nxt Hdr: 8-bit selector. Identifies the type of header immediately following the
Hop-by-Hop or Desitnation Options header. Uses the same values as the IPv4 Protocol

This comment has been minimized.

Copy link
@mhira1

mhira1 Oct 3, 2018

Contributor

Typo: Desitnation -> Destination

Hop-by-Hop or Desitnation Options header. Uses the same values as the IPv4 Protocol
Field [IANA-PN]

HDR Ext Len: 8-bit unsigned integer. Length of the Hop-by-Hop or Desitnation

This comment has been minimized.

Copy link
@mhira1

mhira1 Oct 3, 2018

Contributor

Same typo: Desitnation -> Destination

| Payload + Padding (L4/ESP/….) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


This comment has been minimized.

Copy link
@mhira1

mhira1 Oct 3, 2018

Contributor

We need to add some text to clarify the following regarding INT within IPv6:

  1. What is the use-case for INT as IPv6 destination option? INT has its own destination header type, meant for the INT sink. In general, INT sink and IPv6 destination may not be the same.
  2. How does an INT switch handle the padding following INT data? Each hop inserts Hop-ML worth of metadata which is a multiple of 4 bytes, but not necessarily a multiple of 8 bytes. What happens if each hop is inserting an odd multiple of 4 bytes which is not a multiple of 8 bytes (say 20B). In such a case, at hop 1, we need 4 bytes of padding. Hop 2 can remove the padding inserted by hop 1 and comply. Hop 3 can insert 4 bytes padding again. Or do we say that each hop adds 4B of padding if HopML is an odd multiple of 4B? That would be wasteful.
  3. Regardless of what we do for #2, when HopML is an odd multiple of 4, each hop needs to push metadata at the top of the stack and do some manipulation (add/remove padding) at end of the stack. So INT behavior is different here. In other encapsulations, each hop simply inserts at the head of the metadata stack.

This comment has been minimized.

Copy link
@rsivakolundu

rsivakolundu Oct 4, 2018

Author Contributor

Let us discuss the padding issue in person.

Geneve options to be defined for INT Headers.

### INT over IPv6

This comment has been minimized.

Copy link
@mhira1

mhira1 Oct 3, 2018

Contributor

Should we add INT over IPv6 after the other three encaps? Specially because the text in the paragraph is referring to scenarios where "INT over VXLAN or Geneve is not helpful"

This comment has been minimized.

Copy link
@rsivakolundu

rsivakolundu Oct 4, 2018

Author Contributor

I followed what was done earlier. TCP/UDP was listed first and it referenced encaps. I just stuck to that. I am fine with changing the order.

This comment has been minimized.

Copy link
@jafingerhut

jafingerhut Oct 5, 2018

I may be woefully out of date on IPv6 extension header behavior, but regarding the option '"INT over IPv6" - INT Headers are carried in the IPv6 packets as Hop-by-Hop option.', I had thought that switches in practice have to punt packets with an IPv6 Hop-by-Hop extension header to the slow path, e.g. software forwarding on a general purpose CPU.

I did a quick search and found that RFC 7045 (published Dec 2013) says this in Section 2.2 "Hop-by-Hop Options":

The IPv6 Hop-by-Hop Options header SHOULD be processed by
intermediate forwarding nodes as described in [RFC2460]. However, it
is to be expected that high-performance routers will either ignore it
or assign packets containing it to a slow processing path. Designers
planning to use a hop-by-hop option need to be aware of this likely
behaviour.

Is there really a desire to put INT data into a header that will likely result in slow path processing in the network?

@mhira1 mhira1 requested review from mickeyspiegel and jklr Oct 3, 2018

@jklr

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2018

@rsivakolundu @mhira1 @mickeyspiegel We can merge this change first, create a v1.x cut, advance INT.mdk to version 2 and merge the two other changes. One thing we need to discuss is where to merge the other future transportations (SRv6, GRE) to. INT v1.x or 2.x, or both?

. . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Variable Opt Data (INT Data) | Padding | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

This comment has been minimized.

Copy link
@mickeyspiegel

mickeyspiegel Oct 4, 2018

Contributor

This alignment is not correct. This needs to be either:

  • Option Type and Opt Data Len is in this position, no Reserved (MBZ) field, and no padding, and the option has an alignment constraint of 4n+2.
  • The option has an alignment constraint of 4n, so there are two bytes of padding after HDR Ext Len, then Option Type and Opt Data Len starting at byte 4, then two bytes of Reserved (MBZ), then INT data.

This comment has been minimized.

Copy link
@rsivakolundu

rsivakolundu Oct 4, 2018

Author Contributor

IOAM did it this way. I am okay with your suggestion. I will close with IOAM folks on a separate thread.

This comment has been minimized.

Copy link
@mickeyspiegel

mickeyspiegel Oct 4, 2018

Contributor

I think IOAM did my second bullet. They did not explicitly mention the 4n alignment constraint, but they should have. That is the only way that what they defined works.

I need to propose to ask for only one code point and replace Reserved (MBZ) with 1 byte reserved and 1 byte IOAM Type.

Option Type: 8-bit identifier of the type of option.

001xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_INT_HOP_BY_HOP_OPTION_IPV6.
001xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_INT_DESTINATION_OPTION_IPV6.

This comment has been minimized.

Copy link
@mickeyspiegel

mickeyspiegel Oct 4, 2018

Contributor

Looking at the IANA registry, there are a total of 32 code points of which 17 have already been allocated. The registration procedure is IESG Approval, IETF Review or Standards Action. IOAM is asking for 4 code points, which seems unlikely. The chances for INT to get any code points are not high.

This comment has been minimized.

Copy link
@rsivakolundu

rsivakolundu Oct 4, 2018

Author Contributor

I agree.

Variable Opt Data: INT Header and Metadata, multiple of four octets in length.

Padding: 16-bit pad. Needed to ensure that the variable length of the complete
Hop-by-Hop or Destination Options Header is an integer multiple of 8 octets long.

This comment has been minimized.

Copy link
@mickeyspiegel

mickeyspiegel Oct 4, 2018

Contributor

I don't think the padding is added explicitly. If there are multiple options in the same extension header, then padding is only inserted to meet the next option's alignment constraint. The padding to 8 bytes is done at the end, after all options have been added to the extension header.

What I suggested for IOAM is that the Hop ML must be even so that padding is not required. However, I did not consider that the INT header is included. For v1 and with the second padding option described above, if Hop ML is even no padding would be required. For v2 due to the odd number of octets before the per hop data, this would not work and padding would have to be added in some cases.

rsivakolundu added 3 commits Oct 4, 2018
@rsivakolundu

This comment has been minimized.

Copy link
Contributor Author

commented Oct 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.