Brian E Carpenter <[email protected]> writes: > > 2) The routing header is essentially deprecated, and we probably won't > > define any more.
> The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, > is active. Oh, right. But I view that as (essentially) an L2 usage. It will be used within one RPL domain, which is essentially its own link layer. Within an RPL, all IPv6 datagrams that come from outside the domain are encapsulated within a new IPv6 packet, so the outer IPv6 packet (with the RH4 header) is like a link-layer encapsulation. > However, isn't the real question whether we want to change the > implied intention that adding a new extension header should be > hard? Section 4 of RFC 2460 makes this intention pretty clear: > unknown extension headers should lead to packet discard and > ICMP Parameter Problem, so this is intended for consenting adults > only. Skipping over unknown extension headers was definitely > not intended to work. I don't think it's right to say 2460 intends to make defining new options "hard". Or more to the point, this document doesn't make defining new options any easier (from what I can see). The text in Section 4 is about how the intended recipient of an option is supposed to process it. If the intended recipient doesn't understand an option, that's arguably a bad situation. And the various 2460 definitions provide a way for the sender to get predictable (and reasonable) behavior in such situations. The alleged purpose of this document is to provide a way for devices that are NOT the intended recipient of an option to do "sensible things" with on option they don't understand, which is a sort of oxymoron. > The basic motivation for the present draft is clear: > > However, > > some intermediate nodes such as firewalls, may need to look at the > > transport layer header fields in order to make a decision to allow or > > deny the packet. > That is, help middleboxes to violate e2e transparency and, furthermore, > allow unknown headers to cross those middleboxes. If I was a paranoid > security person, I would definitely not be happy with this. On the > contrary - if I saw an unknown IP header in a packet, I would want > to discard it. A legacy firewall wouldn't recognize the Next Header > value for draft-ietf-6man-exthdr, so would discard the packet. If my > firewall had been updated, and saw a draft-ietf-6man-exthdr, header, > it would need to look at the embedded "Specific Type" and then decide > whether to discard it. Just a bit more deep packet inspection. But it is a very open question whether any middlebox will bother to do this. > So the one thing this proposal will *not* do is allow new extension headers > to cross the Internet transparently. All it might do is cause the firewalls > to dig one layer deeper before discarding the packet. This is at best poorly phrased. :-) If the firewall will just dig one layer deeper and then discard anyway, what is the point? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
