Le 4 janv. 2011 à 16:20, Steven Blake a écrit :

> On Tue, 2011-01-04 at 09:20 -0500, Thomas Narten wrote:
>> 
>> If the firewall will just dig one layer deeper and then discard
>> anyway, what is the point?
> 
> +1
> 
> I still don't understand what this draft solves that couldn't be solved
> more easily by just encoding future header extensions as either
> Destination options or Hop-by-Hop options?


1.
let's assume a new routing extension is found useful.
Without a skippable extension format, it won't ever  be deployable:
- All FWs will have no option but rejecting all packets having it.

With this extension format, FWs can first be upgraded to support it, i.e. so 
that they ignore unknown extensions marked as "to be ignored if unknown".
Then it becomes realistic to create, for example, a new routing option.

2.
Attached is a copy of a previous mail, still relevant I believe.


Regards,
RD



> Le 3 janv. 2011 à 14:20, Suresh Krishnan a écrit :
>> ...
>> The draft contains three independent components
>> 
>> a) Specifying a uniform format for all future IPv6 extension headers to
>> make them easier to parse/process.
>> b) Requesting a single IP protocol number codepoint for all future
>> extension headers and multiplexing them using a Specific Type field
>> inside the generic header.
>> c) Specifying error-handling and drop behavior for dealing with unknown
>> extension headers.
> 
>> From what I have seen there seems to be no opposition to a)
> 
> No opposition AND positive support:
> 
> Skipping unknown extension headers can be useful not only in FWs but also in 
> some other places (e.g. in some variants of load balancers) 
> 
> As Fernando noted, FWs that do "default deny" shouldn't be concerned.
> However, not all FWs are necessarily default deny in the strict sense (i.e. 
> with all fields of accepted packets having to be described)
> It may be useful to say, for example, "accept all incoming connections to 
> address X and port 80" without concern for extension headers.
> 
> Besides, someone, Mark Townsley I believe, described a FW behavior where:
> - packets known to be good are accepted
> - packets known to be bad are discarded
> - unknown packets are rate limited
> This is IMHO an interesting possibility that differs from just "default deny".
> 
> Points b and c are more debatable.
> I don't find them necessary.
> The draft would IMHO be better without them,  but I don't object.
> 
> The proposed addition in the "Meta question" seems useful => +1
> (But the document remains acceptable without it.)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to