> 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. 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. 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. 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. Regards Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
