Mailing List Archive: nsp: ipv6

Extension headers and firewalls

Index | Next | Previous | View Threaded

brian.e.carpenter at gmail

Jul 20, 2012, 1:10 AM

Post #1 of 21 (1413 views)
Permalink

Extension headers and firewalls

I'm hearing that shim6 headers are blocked by the BSD pf firewall, and that
the problem extends to other types of extension header.

I'm also hearing that PIX boxes are said to drop shim6 headers.

Does anybody have clear information about this?

Regards
Brian Carpenter

ek at google

Jul 20, 2012, 1:17 AM

Post #2 of 21 (1376 views)
Permalink

Re: Extension headers and firewalls [In reply to]

I know that (at least some models of) Brand J router ACLs can't filter when
there are extension headers so the packets are usually just dropped.
Extension headers, and by extension, fragmentation, really kinda just
don't work in the IPv6 world right now. :-(

On 20 July 2012 17:10, Brian E Carpenter <brian.e.carpenter [at] gmail>wrote:

> I'm hearing that shim6 headers are blocked by the BSD pf firewall, and that
> the problem extends to other types of extension header.
>
> I'm also hearing that PIX boxes are said to drop shim6 headers.
>
> Does anybody have clear information about this?
>
> Regards
> Brian Carpenter
>
>
>

simon.perreault at viagenie

Jul 20, 2012, 7:07 AM

Post #3 of 21 (1374 views)
Permalink

Re: Extension headers and firewalls [In reply to]

Le 2012-07-20 04:10, Brian E Carpenter a écrit :
> I'm hearing that shim6 headers are blocked by the BSD pf firewall, and that
> the problem extends to other types of extension header.

pf has no special knowledge of shim6. It considers shim6 as a transport
protocol and doesn't look beyond it. So the only way to make pf pass
shim6 packets is with a "pass" rule allowing all protocols or with a
"pass proto 140" rule allowing the shim6 header specifically (but then
you can't filter based on what follows).

It should be fairly easy (and fun!) to add. Check out pf_walk_header6()
in pf.c:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c?rev=1.808

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca

merike at doubleshotsecurity

Jul 21, 2012, 12:58 PM

Post #4 of 21 (1372 views)
Permalink

Re: Extension headers and firewalls [In reply to]

Just last week I had posted on a security mailing list that my favorite litmus test question for vendors who supported IPv6 was 'How do you handle extension headers'? Sadly, there is a lot of work to do here with most vendors. And I've been asking this for at least 2 years. Very often it's an issue with performance since the ASIC designs to accommodate a variable packet header sizes isn't so straightforward, or so I'm told :)

- merike

On Jul 20, 2012, at 1:17 AM, Erik Kline wrote:

> I know that (at least some models of) Brand J router ACLs can't filter when there are extension headers so the packets are usually just dropped. Extension headers, and by extension, fragmentation, really kinda just don't work in the IPv6 world right now. :-(
>
>
> On 20 July 2012 17:10, Brian E Carpenter <brian.e.carpenter [at] gmail> wrote:
> I'm hearing that shim6 headers are blocked by the BSD pf firewall, and that
> the problem extends to other types of extension header.
>
> I'm also hearing that PIX boxes are said to drop shim6 headers.
>
> Does anybody have clear information about this?
>
> Regards
> Brian Carpenter
>
>
>

cb.list6 at gmail

Jul 21, 2012, 1:38 PM

Post #5 of 21 (1367 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On Jul 20, 2012 1:17 AM, "Erik Kline" <ek [at] google> wrote:
>
> I know that (at least some models of) Brand J router ACLs can't filter
when there are extension headers so the packets are usually just dropped.
Extension headers, and by extension, fragmentation, really kinda just
don't work in the IPv6 world right now. :-(
>
>

Perhaps this functionality should be officially depricated.

CB

> On 20 July 2012 17:10, Brian E Carpenter <brian.e.carpenter [at] gmail>
wrote:
>>
>> I'm hearing that shim6 headers are blocked by the BSD pf firewall, and
that
>> the problem extends to other types of extension header.
>>
>> I'm also hearing that PIX boxes are said to drop shim6 headers.
>>
>> Does anybody have clear information about this?
>>
>> Regards
>> Brian Carpenter
>>
>>
>

jared at puck

Jul 21, 2012, 5:09 PM

Post #6 of 21 (1369 views)
Permalink

Re: Extension headers and firewalls [In reply to]

You might find a lot of support for this I suspect.

Jared Mauch

On Jul 21, 2012, at 4:38 PM, Cameron Byrne <cb.list6 [at] gmail> wrote:

> Perhaps this functionality should be officially depricated.
>
> CB
>

brian.e.carpenter at gmail

Jul 22, 2012, 12:55 AM

Post #7 of 21 (1363 views)
Permalink

Re: Extension headers and firewalls [In reply to]

hang on - Cameron's statement is ambiguous.

Does it mean "firewalls blocking legal extension headers should be deprecated"
or "hosts sending legal extension headers should be deprecated"?

One of the problems here, as was mentioned on an IETF list quite recently,
is that RFC 2460 specifies behaviour *only* for the extension headers
defined in RFC 2460, and there is no clear list in any RFC or at IANA
of the current set of legal extension headers. Firewall implementers
seem to go by RFC 2460 alone.

This is a gap that needs to be filled by the IETF (imho).

Brian

On 22/07/2012 01:09, Jared Mauch wrote:
> You might find a lot of support for this I suspect.
>
> Jared Mauch
>
> On Jul 21, 2012, at 4:38 PM, Cameron Byrne <cb.list6 [at] gmail> wrote:
>
>> Perhaps this functionality should be officially depricated.
>>
>> CB
>>
>

gert at space

Jul 22, 2012, 3:40 AM

Post #8 of 21 (1362 views)
Permalink

Re: Extension headers and firewalls [In reply to]

Hi,

On Sat, Jul 21, 2012 at 01:38:06PM -0700, Cameron Byrne wrote:
> On Jul 20, 2012 1:17 AM, "Erik Kline" <ek [at] google> wrote:
> >
> > I know that (at least some models of) Brand J router ACLs can't filter
> when there are extension headers so the packets are usually just dropped.
> Extension headers, and by extension, fragmentation, really kinda just
> don't work in the IPv6 world right now. :-(
> >
> >
>
> Perhaps this functionality should be officially depricated.

Which functionality? Extention headers, or "limited implementations that
fall over extention headers, but get marketed as 'full IPv6 support'"?

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

cb.list6 at gmail

Jul 22, 2012, 9:08 AM

Post #9 of 21 (1362 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
<brian.e.carpenter [at] gmail> wrote:
> hang on - Cameron's statement is ambiguous.
> Does it mean "firewalls blocking legal extension headers should be deprecated"
> or "hosts sending legal extension headers should be deprecated"?
>

The latter.

Per RFC 2460, firewalls and routers should not be processing extension
headers. I believe this is also a good case study in what the IETF
can specify and what industry will deliver and use.

To be clear, I do not see any value is carrying forward the path for
more functionality at the internet layer. The internet layer should
just move packets from A to B (hour glass model, e2e model, ....).
Upper layers are better at handling the things extension headers were
trying to do (mobility, e2e security, max segment size / fragment /
path mtu...).

The solution (extension headers) has not yet found it's problem in 10+
years. In the meantime, it has created a great deal of confusion.
And now, you have people reading RFC 2460, they think they understand
IPv6, and then go to find out that so much text in 2460 to describe
extension headers is not a reality on the internet.

The intent of 2460 was good, but it did not match the trajectory of
the internet with regards application functionality, security policy,
and packet forwarding architectures evolved.

CB

> One of the problems here, as was mentioned on an IETF list quite recently,
> is that RFC 2460 specifies behaviour *only* for the extension headers
> defined in RFC 2460, and there is no clear list in any RFC or at IANA
> of the current set of legal extension headers. Firewall implementers
> seem to go by RFC 2460 alone.
>
> This is a gap that needs to be filled by the IETF (imho).
>
> Brian
>
> On 22/07/2012 01:09, Jared Mauch wrote:
>> You might find a lot of support for this I suspect.
>>
>> Jared Mauch
>>
>> On Jul 21, 2012, at 4:38 PM, Cameron Byrne <cb.list6 [at] gmail> wrote:
>>
>>> Perhaps this functionality should be officially depricated.
>>>
>>> CB
>>>
>>

brian.e.carpenter at gmail

Jul 22, 2012, 9:25 AM

Post #10 of 21 (1363 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On 22/07/2012 17:08, Cameron Byrne wrote:
> On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
> <brian.e.carpenter [at] gmail> wrote:
>> hang on - Cameron's statement is ambiguous.
>> Does it mean "firewalls blocking legal extension headers should be deprecated"
>> or "hosts sending legal extension headers should be deprecated"?
>>
>
> The latter.
>
> Per RFC 2460, firewalls and routers should not be processing extension
> headers.

Except for HbH options (which I think we can agree are a mistake)
forwarding boxes are supposed to *ignore* extension headers. They
aren't supposed to *discard* them.

Brain

I believe this is also a good case study in what the IETF
> can specify and what industry will deliver and use.
>
> To be clear, I do not see any value is carrying forward the path for
> more functionality at the internet layer. The internet layer should
> just move packets from A to B (hour glass model, e2e model, ....).
> Upper layers are better at handling the things extension headers were
> trying to do (mobility, e2e security, max segment size / fragment /
> path mtu...).
>
> The solution (extension headers) has not yet found it's problem in 10+
> years. In the meantime, it has created a great deal of confusion.
> And now, you have people reading RFC 2460, they think they understand
> IPv6, and then go to find out that so much text in 2460 to describe
> extension headers is not a reality on the internet.
>
> The intent of 2460 was good, but it did not match the trajectory of
> the internet with regards application functionality, security policy,
> and packet forwarding architectures evolved.
>
> CB
>
>
>> One of the problems here, as was mentioned on an IETF list quite recently,
>> is that RFC 2460 specifies behaviour *only* for the extension headers
>> defined in RFC 2460, and there is no clear list in any RFC or at IANA
>> of the current set of legal extension headers. Firewall implementers
>> seem to go by RFC 2460 alone.
>>
>> This is a gap that needs to be filled by the IETF (imho).
>>
>> Brian
>>
>> On 22/07/2012 01:09, Jared Mauch wrote:
>>> You might find a lot of support for this I suspect.
>>>
>>> Jared Mauch
>>>
>>> On Jul 21, 2012, at 4:38 PM, Cameron Byrne <cb.list6 [at] gmail> wrote:
>>>
>>>> Perhaps this functionality should be officially depricated.
>>>>
>>>> CB
>>>>
>

cb.list6 at gmail

Jul 22, 2012, 10:32 AM

Post #11 of 21 (1364 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On Jul 22, 2012 9:25 AM, "Brian E Carpenter" <brian.e.carpenter [at] gmail>
wrote:
>
> On 22/07/2012 17:08, Cameron Byrne wrote:
> > On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
> > <brian.e.carpenter [at] gmail> wrote:
> >> hang on - Cameron's statement is ambiguous.
> >> Does it mean "firewalls blocking legal extension headers should be
deprecated"
> >> or "hosts sending legal extension headers should be deprecated"?
> >>
> >
> > The latter.
> >
> > Per RFC 2460, firewalls and routers should not be processing extension
> > headers.
>
> Except for HbH options (which I think we can agree are a mistake)
> forwarding boxes are supposed to *ignore* extension headers. They
> aren't supposed to *discard* them.
>

Agreed, that is what the rfc says.

But implementers have explicitly choosen that they will not ignore them for
the reasons i explained below. Also alluded to below is the limited role of
the ietf.

More generally, industry will not make any changes without business
justification and will not make security or performance trade offs for the
sake of an rfc. This is only my observation of the emergent evolution of
the internet technologies.

Internet evolution (critcal mass of implementers) has selected 128 bit
addresses.

Just like evolution of humans has selected bipedalism and not tails.

CB

> Brain
>
> I believe this is also a good case study in what the IETF
> > can specify and what industry will deliver and use.
> >
> > To be clear, I do not see any value is carrying forward the path for
> > more functionality at the internet layer. The internet layer should
> > just move packets from A to B (hour glass model, e2e model, ....).
> > Upper layers are better at handling the things extension headers were
> > trying to do (mobility, e2e security, max segment size / fragment /
> > path mtu...).
> >
> > The solution (extension headers) has not yet found it's problem in 10+
> > years. In the meantime, it has created a great deal of confusion.
> > And now, you have people reading RFC 2460, they think they understand
> > IPv6, and then go to find out that so much text in 2460 to describe
> > extension headers is not a reality on the internet.
> >
> > The intent of 2460 was good, but it did not match the trajectory of
> > the internet with regards application functionality, security policy,
> > and packet forwarding architectures evolved.
> >
> > CB
> >
> >
> >> One of the problems here, as was mentioned on an IETF list quite
recently,
> >> is that RFC 2460 specifies behaviour *only* for the extension headers
> >> defined in RFC 2460, and there is no clear list in any RFC or at IANA
> >> of the current set of legal extension headers. Firewall implementers
> >> seem to go by RFC 2460 alone.
> >>
> >> This is a gap that needs to be filled by the IETF (imho).
> >>
> >> Brian
> >>
> >> On 22/07/2012 01:09, Jared Mauch wrote:
> >>> You might find a lot of support for this I suspect.
> >>>
> >>> Jared Mauch
> >>>
> >>> On Jul 21, 2012, at 4:38 PM, Cameron Byrne <cb.list6 [at] gmail> wrote:
> >>>
> >>>> Perhaps this functionality should be officially depricated.
> >>>>
> >>>> CB
> >>>>
> >

spz at serpens

Jul 22, 2012, 3:00 PM

Post #12 of 21 (1361 views)
Permalink

Re: Extension headers and firewalls [In reply to]

Thus wrote Brian E Carpenter (brian.e.carpenter [at] gmail):

> On 22/07/2012 17:08, Cameron Byrne wrote:
> > On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
> > <brian.e.carpenter [at] gmail> wrote:
> >> hang on - Cameron's statement is ambiguous.
> >> Does it mean "firewalls blocking legal extension headers should be deprecated"
> >> or "hosts sending legal extension headers should be deprecated"?
> >>
> >
> > The latter.
> >
> > Per RFC 2460, firewalls and routers should not be processing extension
> > headers.
>
> Except for HbH options (which I think we can agree are a mistake)
> forwarding boxes are supposed to *ignore* extension headers. They
> aren't supposed to *discard* them.

Yet when a feature gets used as an attack vehicle, arguing that firewalls
should still ignore its presence is missing the point of firewalls.

Guidance how to handle them well might be more useful here.

regards,
spz
--
spz [at] serpens (S.P.Zeidler)

merike at doubleshotsecurity

Jul 22, 2012, 3:17 PM

Post #13 of 21 (1360 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On Jul 22, 2012, at 3:00 PM, S.P.Zeidler wrote:

> Thus wrote Brian E Carpenter (brian.e.carpenter [at] gmail):
>
>> On 22/07/2012 17:08, Cameron Byrne wrote:
>>> On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
>>> <brian.e.carpenter [at] gmail> wrote:
>>>> hang on - Cameron's statement is ambiguous.
>>>> Does it mean "firewalls blocking legal extension headers should be deprecated"
>>>> or "hosts sending legal extension headers should be deprecated"?
>>>>
>>>
>>> The latter.
>>>
>>> Per RFC 2460, firewalls and routers should not be processing extension
>>> headers.
>>
>> Except for HbH options (which I think we can agree are a mistake)
>> forwarding boxes are supposed to *ignore* extension headers. They
>> aren't supposed to *discard* them.
>
> Yet when a feature gets used as an attack vehicle, arguing that firewalls
> should still ignore its presence is missing the point of firewalls.
>
> Guidance how to handle them well might be more useful here.

+1

not to mention the RH-Type0 filtering which most routers had incorporated

I struggle with wanting a clean end-to-end model but having capability of catching malware as close to source as possible.

- merike

tore.anderson at redpill-linpro

Jul 22, 2012, 11:04 PM

Post #14 of 21 (1361 views)
Permalink

Re: Extension headers and firewalls [In reply to]

* Erik Kline

> > I know that (at least some models of) Brand J router ACLs can't
> > filter when there are extension headers so the packets are usually
> > just dropped. Extension headers, and by extension, fragmentation,
> > really kinda just don't work in the IPv6 world right now. :-(

Extension headers are certainly often filtered by end sites, perhaps
sometimes overzealously. But that's nothing new, the same thing is true
for ICMP, for example, or even anything that is not 80/tcp.

The good news is that ISPs and backbone carriers generally don't filter
them. So if two end sites want to communicate using functionality
provided by extension headers, and neither of them filter them, it will
likely work just fine.

* Cameron Byrne

> Perhaps this functionality should be officially depricated.

That would take important features with it such as IPSEC and Mobile
IPv6 down with it (both of which I've seen working over the public
IPv6 internet). Also, fragmentation is often used inside individual
end sites - I see my OSPFv3 sessions make use of it all the time,
for example.

So you can't deprecate extension headers just like that. You'll
first have to replace the functionality they offer with alternate
methods.

Tore

brian.e.carpenter at gmail

Jul 22, 2012, 11:57 PM

Post #15 of 21 (1359 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On 22/07/2012 23:00, S.P.Zeidler wrote:
> Thus wrote Brian E Carpenter (brian.e.carpenter [at] gmail):
>
>> On 22/07/2012 17:08, Cameron Byrne wrote:
>>> On Sun, Jul 22, 2012 at 12:55 AM, Brian E Carpenter
>>> <brian.e.carpenter [at] gmail> wrote:
>>>> hang on - Cameron's statement is ambiguous.
>>>> Does it mean "firewalls blocking legal extension headers should be deprecated"
>>>> or "hosts sending legal extension headers should be deprecated"?
>>>>
>>> The latter.
>>>
>>> Per RFC 2460, firewalls and routers should not be processing extension
>>> headers.
>> Except for HbH options (which I think we can agree are a mistake)
>> forwarding boxes are supposed to *ignore* extension headers. They
>> aren't supposed to *discard* them.
>
> Yet when a feature gets used as an attack vehicle, arguing that firewalls
> should still ignore its presence is missing the point of firewalls.
>
> Guidance how to handle them well might be more useful here.

Yes indeed. To consider my own hobby-horse, blindly dropping all packets
containing shim6 headers is really bad. Dropping shim6 packets that do
not use the shim6 anti-spoofing security mechanism would be a reasonable
option in a security policy.

As Tore said: as long as this mechanism is needed, firewalls should
handle it correctly.

That seems clear enough for this mailing list - looks like some work
is needed in IETF-land.

Brian

evyncke at cisco

Jul 23, 2012, 1:15 AM

Post #16 of 21 (1370 views)
Permalink

RE: Extension headers and firewalls [In reply to]

Brian,

Assuming that by PIX you actually mean Cisco ASA (the new name), then indeed by default (prior version 8.4.2) ASA drops all packets containing RH0 or unknown extension header/layer-4 protocol (hence probably blocking also shim6). Since version 8.4.2, you can selectively permit/deny any specific extension header.

Hope it helps

-éric

> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com [at] lists [mailto:ipv6-ops-
> bounces+evyncke=cisco.com [at] lists] On Behalf Of Brian E Carpenter
> Sent: vendredi 20 juillet 2012 10:11
> To: ipv6-ops [at] lists
> Subject: Extension headers and firewalls
>
> I'm hearing that shim6 headers are blocked by the BSD pf firewall, and that
> the problem extends to other types of extension header.
>
> I'm also hearing that PIX boxes are said to drop shim6 headers.
>
> Does anybody have clear information about this?
>
> Regards
> Brian Carpenter
>

brian.e.carpenter at gmail

Jul 23, 2012, 5:18 AM

Post #17 of 21 (1361 views)
Permalink

Re: Extension headers and firewalls [In reply to]

Thanks Eric, that seems to be the correct solution for a firewall.
Also of course sites need guidance on the appropriate policy.

Brian

On 23/07/2012 09:15, Eric Vyncke (evyncke) wrote:
> Brian,
>
> Assuming that by PIX you actually mean Cisco ASA (the new name), then indeed by default (prior version 8.4.2) ASA drops all packets containing RH0 or unknown extension header/layer-4 protocol (hence probably blocking also shim6). Since version 8.4.2, you can selectively permit/deny any specific extension header.
>
> Hope it helps
>
> -éric
>
>> -----Original Message-----
>> From: ipv6-ops-bounces+evyncke=cisco.com [at] lists [mailto:ipv6-ops-
>> bounces+evyncke=cisco.com [at] lists] On Behalf Of Brian E Carpenter
>> Sent: vendredi 20 juillet 2012 10:11
>> To: ipv6-ops [at] lists
>> Subject: Extension headers and firewalls
>>
>> I'm hearing that shim6 headers are blocked by the BSD pf firewall, and that
>> the problem extends to other types of extension header.
>>
>> I'm also hearing that PIX boxes are said to drop shim6 headers.
>>
>> Does anybody have clear information about this?
>>
>> Regards
>> Brian Carpenter
>>
>

fw at deneb

Aug 10, 2012, 1:17 PM

Post #18 of 21 (1143 views)
Permalink

Re: Extension headers and firewalls [In reply to]

* Cameron Byrne:

> Per RFC 2460, firewalls and routers should not be processing extension
> headers.

Per RFC 2460, firewalls and routers should not look at port numbers
and other upper-layer protocol data. RFC 2460 (and the whole IPv6
header design) optimizes for a use case that does not exist anymore,
software-based forwarding strictly according to destination address.

Deprecating extension headers is one way forward, except that DNSSEC
needs fragmentation.

brian.e.carpenter at gmail

Aug 11, 2012, 12:26 AM

Post #19 of 21 (1132 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On 10/08/2012 21:17, Florian Weimer wrote:
> * Cameron Byrne:
>
>> Per RFC 2460, firewalls and routers should not be processing extension
>> headers.
>
> Per RFC 2460, firewalls and routers should not look at port numbers
> and other upper-layer protocol data. RFC 2460 (and the whole IPv6
> header design) optimizes for a use case that does not exist anymore,
> software-based forwarding strictly according to destination address.

Of course it exists. There are forwarding boxes that look at more
than the destination address, but they are by no means the only
forwarding boxes in the Internet.

> Deprecating extension headers is one way forward, except that DNSSEC
> needs fragmentation.

And a whole set of other exceptions. Even abolishing fragmentation,
which would be wonderful, would not be enough.

I agree this is a problem area, but your solution is not realistic.

Brian

bzeeb-lists at lists

Aug 11, 2012, 1:23 PM

Post #20 of 21 (1111 views)
Permalink

Re: Extension headers and firewalls [In reply to]

On Fri, 10 Aug 2012, Florian Weimer wrote:

> Deprecating extension headers is one way forward, except that DNSSEC
> needs fragmentation.

And thanks for taking Ah, ESP, not to say Hop-by-Hop and with that
Jumbograms away. Silly Fragmentation is the least to worry about.

/bz

--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.

fw at deneb

Aug 11, 2012, 1:43 PM

Post #21 of 21 (1110 views)
Permalink

Re: Extension headers and firewalls [In reply to]

* Bjoern A. Zeeb:

> On Fri, 10 Aug 2012, Florian Weimer wrote:
>
>> Deprecating extension headers is one way forward, except that DNSSEC
>> needs fragmentation.
>
> And thanks for taking Ah, ESP, not to say Hop-by-Hop and with that
> Jumbograms away.

AH and hop-by-Hop headers will stop working at some point (if this
hasn't happened yet). ESP is special, not sure what's going to happen
there.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads