Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Fernando Gont <[e-mail]>]

Hello, Lee,

Just to provide a different perspective... ;-)

On 10/23/18 9:50 PM, Lee Howard wrote:
[....]
> 
> Looking at recent (past two years) 6man documents. . .
> 
> draft-ietf-6man-segment-routing-header
> I think multiple interoperable implementations exist.

.. which go against RFC8200 and the consensus of this wg. (eh insertion)


> 
> draft-ietf-6man-icmp-limits
> Specifies ICMPv6 error messages.
> It's -00, but we should look for running code before publication.

Should look at the doc.. but implementations normally do rate limiting,
already.



> draft-ietf-6man-rfc4941bis-00
> Also -00, but I'd hope to see code before publication.

... or not. If there are, there will be more cycles spent on it as/if
the document is tweaked on the way to its publication.



> RFC 8425 (was draft-ietf-6man-ndpioiana)
> IANA Considerations for IPv6 Neighbor Discovery Prefix Information
> Option Flags
> No running code applicable.
> 
> RFC 8319 (was draft-ietf-6man-maxra)
> Support for Adjustable Maximum Router Lifetimes per Link
> I think we had seen code; not sure, but I don't recall objections from
> implementers.

Many implementers don't follow our process, though. And there can also
be cases of folks working with the network code of an OS, without
devoting a lot of thought to protocol design/engineering. (it may or may
not be the case)



> RFC 8200 (was draft-ietf-6man-rfc2460bis)
> Internet Protocol, Version 6 (IPv6) Specification Errata        2017-07
> Decades of running code.

Yes and not. Flow Label is pretty recent. There's not much real-world
experience with EHs at global scale, and some of the updates were fairly
recent (although there was running code).



> RFC 8201 (was draft-ietf-6man-rfc1981bis)
> Path MTU Discovery for IP version 6
> Decades of running code.

This one is tricky. Code was "running", but PMTUD known to be
problematic on the public Internet. (That's why we produced PLPMUTD in
the first place).



> RFC 8106 (was draft-ietf-6man-rdnss-rfc6106bis)
> IPv6 Router Advertisement Options for DNS Configuration
> We had running code.
>
> RFC 8064 (was draft-ietf-6man-default-iids)
> Recommendation on Stable IPv6 Interface Identifiers
> No running code applicable

There was running code for RFC7217, which is what RFC8064 recommends. By
the time RFC7217 was published, there was, at east, a Linux kernel
implementation. Most implementations came after RFC7217 -- although I
did do my best to socialize stable-privacy with developers.



> RFC 8021 (was draft-ietf-6man-deprecate-atomfrag-generation)
> Generation of IPv6 Atomic Fragments Considered Harmful
> No running code applicable.

By the time this go published, the corresponding change had already been
comited to the Linux kernel.


> So, requesting running code for the ipv6only-flag isn't really a change
> in practice for 6man. We just haven't had to ask before.

I'd say there have been varying experiences. As an author, getting
implementers involved (no matter there's code or not) helps spot stuff
that should be clarified, learn about details of different
implementations (e.g. some of our assumptions may not apply to all
implementations), etc. However, what happens with one implementation
need not apply to others. For example, it is probably quite different to
do RFC7217 in the kernel vs in a daemon such as dhcpcd (which many OSes
employ nowadays).

In this particular case (ipv6-only flag), what goes on the wire is
simple enough that..I don't think having an implementation will buy much
wrt how different implementations interoperate with each other. And the
insights you'll gain from an implementation are most likely "out of the
scope of the I-D", since how you disable the IPv4 stack is certainly
going to be very implementation-dependent. (me thinking out loud)

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492