Date: Sat, 25 Jun 2005 10:25:24 -0700
From: Bob Hinden <bob.hinden@xxxxxxxxx>
Message-ID: <6.2.1.2.2.20050625093133.027d63a0@xxxxxxxxxxxxxxxxxxxxxxx>
| There are IPv6 option types available, but this was a request for an IPv6
| hop-by-hop option.
I had always assumed that the option space for HBH and Dest-Options was
the same. Perhaps I'm wrong about that, but it doesn't really matter.
| The IPv6 hop-by-hop options (like all IPv4 options and
| one of the reasons that IPv4 options never had much use) have a significant
| performance impact for all routers that forward packets with hop-by-hop
| options in them.
No, that's not quite correct. The performance impact (in v6) is for
packets with the HBH header in them. Whether the header is filled with
a dozen NOP (pad) options, or some other option, really makes little
difference. I guess one could optimise for packets with one (or perhaps
some other small number) of particularly likely HBH headers in them,
should such things ever become common, but even a minor variation is
going to mean slowing down processing, with no new option codes beyond
what exist today.
| I think it is quite reasonable to not assign any new ones
| without serious IETF discussion.
This does absolutely no good if your concern is internet performance.
Anyone can send packets with any options in them that they like -
publically defined or not, using IANA assigned code points or not.
The options already have the number space divided into "reject packet"
and "just ignore this option" for unknown options, and options all
have a defined overall format, so skipping unrecognised ones is always
possible (at a performance cost, of course).
What's really important with option assignments is whether or not
it is possible to implement the option, should one decide to, and do
it in a way that you can reasonably hope that all users of a particular
option code are using it the same way. Doing that means making it
(relatively) easy to register code points, not difficult.
| I also don't have any problem with the
| bar for new IPv6 hop-by-hop options to be set very high.
Same point, doing this achieves nothing. On the other hand,
it is totally reasonable to advise people against using HBH,
and explain why. But if they are going to, they will, regardless.
We have plenty of experience with all kinds of people "making up"
allocations for values in all kinds of data fields through the
internet, and then with everyone having to work around this later,
somehow guessing which values have been taken by various implementations,
and then avoiding assigning those (doing registry "catch up") later.
Can't we learn from that experience, and avoid repeating the same
mistakes, over and over?
| I belive the IESG did the right thing in this case as it was a request for
| an IPv6 hop-by-hop option.
You mean to take the decision out of your hands, and make it on your
behalf, instead of initiating the "serious IETF discussion" you suggest
above? Really? Recall that they didn't say "you need to discuss
this in the IETF first" what they said was "go away, proposal is junk,
no option code for it".
| I did a quick review of the link at the end of | the IESG email
I didn't. Precisely because it doesn't matter to me what the
quality of the proposal is, nor whether an option code should
actually be allocated to this or not. What matters is the way
the IESG decided to deal with it.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf