Re: [Spud] updated draft PLUS charter, rev. 1 June

[Tom Herbert <[e-mail]>]

On Wed, Jun 22, 2016 at 12:24 PM, Joe Touch <[e-mail]> wrote:
> See below.
>
> On 6/20/2016 10:10 AM, Tom Herbert wrote:
>>> I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers might have reflection-reducing properties, given the installed base. We should look into that more deeply.
>>>
>> The solution would be to use hop-by-hop options. These would have a
>> lot of advantages:
>>
>> - HBH options work with any transport or IP protocol (TCP, SCTP, UDP,
>> IPsec, GRE, etc.) not just new UDP based transport protocols. This
>> means adding host to network signaling could be done as an incremental
>> change to the existing mostly TCP Internet (I think this is a major
>> benefit).
>
> Except that they also increase the chance your packets are just dropped
> at routers, or that they will take the slow-path.
>
>> - For a fragmented packet each fragment can contain hop-by-hop options
>> but not each one contains transport headers.
>> - Hop-by-hop options must be first extension header in the packet so a
>> network device only needs to parse the IPv6 header and one type of EH.
>> If a middlebox has to access the transport layer header and payload it
>> would need to be able to parse over other types of extension headers
>> (routing, DO, etc.)
>
> Except that they tend to want to jump over only a small number of such
> options; increasing that number increases the chance the packet is dropped.
>
Per RFC2460 those devices should not be jumping over any options at
all, this is non standard behavior. This is why we need Happy Eyeballs
in order to work around non-compliant devices. We need workarounds for
IPv6 anyway, and we would need them when trying to replace TCP with
UDP based transport protocol or something else. IMHO I don't believe
that the fact that some number of devices don't comply with the
standard justifies creating a whole new standard to accomplish the
same effect while potentially opening the door for new ways to be
noncompliant.

Tom

>> - HBH can be replicated as desired in the outer headers if packets go
>> through an IP tunnel.
> HBH options almost never make sense to copy. They're useful in the
> context of the original header, not the new one.
>
> You'd have to define the desire to copy your header if that's the
> behavior you want, and you'd need a way to know when that didn't happen.
>
> However, this is a really nonsensical idea - the whole point of a tunnel
> is to present a virtual LINK - not an IP subpath. Nothing that happens
> on a link needs to be visible to IP unless it's already visible at the
> link endpoints -- which is where the tunneled packet's HBH options are
> already processed.
>
>> - IP protocol numbers are unambiguous. If IPv6 next-hdr value is 0 the
>> next header in a packet contains an extension header as a global
>> invariant. No magic numbers needed.
>> - Extension headers are not automatically reflected by any service.
> I'll bet money that they are.
>
>> - It is within the protocol to modify the contents of HBH options (as
>> specified in the definition of an option). There is also no checksum
>> that needs to be updated unlike the case of UDP payload being
>> modified.
>> - The rules for processing HBH options are being relaxed in 2460bis.
>> Previously, all nodes in a path were required to inspect them. The new
>> text allows nodes in the path to ignore them and forward packets as
>> without processing or modifying HBH options.
> That also means that legacy devices might not behave as you expect.
>> - RFC3542 defines a sockets API that seems to be supported by the
>> major OSes. Applications probably are permitted to set arbitrary
>> options in packets that may affect the network, however allowing
>> application specific options that are deemed safe can done by
>> whitelist.
>
> FWIW, ick. RFCs shouldn't be man pages. IPv6 (more specifically,
> RFC2460-bis) should include an abstract API that vendors can support,
> exactly as RFC793 did.
>> - HBH options obviously only works with IPv6 and is not available in
>> IPv4. I actually think this is a good thing since supporting
>> forwarding looking functionality only in IPv6 would promote continued
>> transition to IPv6 in the Internet and is in alignment with the early
>> efforts for sunsetting IPv4.
>>
> +1 on that point.