Re: Which IPv6 Option Types are reserved for testing?

[Pekka Savola <pekkas@netcore.fi>]

(sorry for delay)

[personal response, without any hats, obviously]

On Mon, 13 Sep 2004, Jeroen Massar wrote:
> I am currently extending AYIYA to do proper multihoming.
> As I intend to do wider-scale testing, outside of the very small test
> setup I am currently using, I was wondering what Option Types are
> reserved or can be used for this kind of testing. Because, just like the
> 206 ICMPv6 option for MLDv2, changing it after it has been circulated
> quite a bit can be a bit painful, indeed it is a part of the kernel.
> Reading: http://www.iana.org/assignments/ipv6-parameters
> 
> It apparently contains no reserved ones. Typically it would need a:
> 
> act chg rest
> --- --- -----
>  11  0  xxxxx AYIYA Option Header
> 
> But what can I use for the last 5 bits?
> Exact contents of this header will come in the next update, -03 version
> of the AYIYA draft, which will also describe how it is used and 
> 
> I could of course fill in a general request form at IANA but then they
> will probably say that you need an RFC and bladiebla... while I just
> want to let people test it first ;) You need implementations of a thing
> anyway before it can become an rfc usually, this there is a small loop
> there.

Unfortunately, the IPv6 specs have provided no IANA assignment policy, 
so it's unclear which one it is.. but at least one person has obtained 
a value without significant documentation, so I guess it might be 
possible to get an assignment even without RFC.

RFC3692 ("Assigning Experimental and Testing Numbers Considered 
Useful") discusses this, but it doesn't help in this case, as an 
experimental number space has not been set up.

I fear I cannot help with this except by stating that there might a 
couple of options:

 1) just pick [illegitimately] a codepoint value for now, or use the 
one used for "endpoint identification", which has probably been dead 
for the last 5 years.

 2) redesign the protocol to use something else than IP options.  In
many cases the IP options are a bad way to go in any case.

 3) bring up the issue in IPv6 WG, asking the WG to produce a document 
which: 1) appropriately documents the IANA assignment policies for 
IANA IPv6 registries [this is IMHO pretty important], and 2) specifies 
an experimental code point values these IANA codepoints.

 4) just try to send in a request for the value and see what happens.

 5) take this as a good opportunity to provide feedback on 
draft-narten-iana-considerations-rfc2434bis-01.txt, which discusses 
the IANA assignment policies, whether this is something that needs to 
be covered better (and if so, how?).

I'd recommend you'd do at least 3), but if you don't, I'll have to
bring this up again, I guess.  If I were you, I'd also consider
whether 2) is a viable option.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings