> If we take the view that a firewall will block anything it does not know, > without question or limit, then > 1) We have no way to extend our basic protocols that will pass through > firewalls (we have to tunnel / encapsulate)
I agree. > 2) you are correct that this document does not help. Disagree. If the Hdr Options is 00, then it will pass through. > > Also, if we assume that no one will ever define any new extension headers, > then this work does not matter. > > (If we want that prohibition to be the case, we should say so, and remove > the hook for new extension headers that was left in 2460.) > > On the other hand, if we think that there will be new extension headers, and > we think that firewalls block things if they can not find enough information > to allow them through, then it can be helpful if the firewalls (and other > devices) can parse pass these new extensions without knowing them. > (Remember, these are for end-point consumption only.) Yes. > > It seems to me a disservice to simultaneously let people use new extension > headers and not give them a way to use them that can be parsed past by the > common devices that could easily want to do such parsing. Yes. > > My own preference would probably be to say that all end-to-end IP > information should be in the destination options. But if we do not want to > go there, then we should own up to the implications thereof. (In > particular, there might be corner cases that can't use destination options. > We should tell people to use destination options first. And tell them what > to do if they can't.) This then could be added in the subsequent versions of this draft. Kam > > Yours, > Joel > > On 1/3/2011 4:43 PM, Fernando Gont wrote: >> >> On 03/01/2011 06:25 p.m., Brian E Carpenter wrote: >> >>> 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. >> >> I don't think this I-D will make a difference. >> >>> From the POV of a firewall, unless it really wants a packet to >> >> pass-through, it will block it. >> >> So, whether the Extension Header is unknown, or whether >> draft-ietf-6man-exthdr-01.txt is implemented and the Specific type is >> unknown will lead to the same result: the packet will be discarded. >> >> This proposal would only be useful to firewalls that implement a >> "default allow", and that simply want to somehow ignore an unknown >> extension header and base their decision on the upper-layer protocol >> (only). -- But we all know that firewalls operate (or should operate) in >> "default deny" rather than "default allow". >> >> So IMHO this proposal won't be useful for such firewalls. >> >> Thanks, > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
