Le 20 avr. 2010 à 19:35, james woodyatt a écrit : > 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.
In my understanding, the draft needs only one, to be standardized rather than experimented. I personally sees no reason to change this (see below) >> 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? If a packet analyzer needs to recognize a protocol above IP: - It skips all extensions headers specified before 2010, with due knowledge of their individual format. - It skips all extension headers specified later (they are identified by their common GIEH number in next-header fields that precedes them, and their lengths are found in their common "Hdr Ext Len" fields). - When it finds a different next-header value, it is that of the protocol above IP. (Then it can do whatever it has to do on the found protocol above IP, e.g process ports numbers if it is TCP, UDP, DCCP, SCTP, and discard others if it is a stateful translator. Its code no longer needs an update if and when new IP-layer extension headers are introduced in the future.) > 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. I agree that this is a bad idea as regards the flow-label discussion, essentially because of what Mark Smith pointed out: this doesn't work on a per packet basis for fragmented IPv6 datagrams. BUT draft-krishnan-ipv6-exthdr-08 was proposed before this discussion, and with a motivation that still holds on its own, and is sufficient in my understanding to justify its endorsement. > 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. Agreed. This should be IMHO the conclusion of the current discussion on flow labels, BUT provided hosts are explicitly permitted to set flow-label values statelessly for each datagram, with a hash of their 5-tuples. (RFC 3697 says "To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence", which privileges flow-label assignments that are stateful per connection, a choice significantly more complex than needed.) Regards, RD > 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 --------------------------------------------------------------------
