On Apr 20, 2010, at 09:56, Rémi Després wrote: > Using the experimental status seems to me confusing (and why two numbers > instead of one?)
There are two numbers reserved for protocols, and I was plagued by the hobgoblins of consistency. I suppose we could assign only one. Or more than two. It's a discussion point. > If the draft becomes a standard-track RFC, as originally proposed but so far > insufficiently supported, we will have all what is needed, simply an cleanly. Okay... how do you propose that IPv6 nodes and/or packet analyzers programmatically distinguish between extension headers and upper-layer transports if they are given only an unrecognized protocol number without access to the online IANA assigned protocol numbers database? I think if you pull on the threads of that question, you will quickly come to a snarly knot of related problems that are A) difficult, and B) probably not worth solving if you bypass them with a simple update to RFC 3692 as I just proposed. ----- To reiterate, I think the original motive for bringing this up, extracting 5-tuples from IPv6 packets, is a bad idea. In general, only some IPv6 packets have 5-tuples, and of those, only a subset can have 5-tuples that packet analyzers can extract, i.e. the rest are encapsulated in ESP or a moral equivalent (and ESP packets have 4-tuples). Hosts should set flow labels. They should probably use RFC 2205 if they need fine-grained resource reservations to claw out marginal capacity in under-provisioned networks. Otherwise, they should ride the best-effort bus like everyone else. -- james woodyatt <j...@apple.com> member of technical staff, communications engineering -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
