Fred, Ran,

On Jan 4, 2012, at 4:11 PM, Templin, Fred L wrote:
> Hi Ran, 
> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On 
>> Behalf Of RJ Atkinson
>> Sent: Wednesday, January 04, 2012 2:44 PM
>> To: [email protected]
>> Subject: Re: Fragmentation-related security issues 
>> 
>> 
>> On 04  Jan 2012, at 16:53 , Templin, Fred L wrote:
>>> "Most deployed IPv4 transit routers disabled all router
>>> fragmentation of IPv4 packets years ago." Are you sure
>>> about that? Because, I have had at least one person from
>>> a major router vendor tell me that router fragmentation
>>> is well supported in their products.
>> 
>> I have no doubt their product possesses the capability.
>> That is subtly different from folks responsible for
>> configuring routers disabling that capability in 
>> particular routers of a particular deployment.
> 
> This can only be done at the peril of black-holing
> DF=0 packets that are too large. Meaning, either the
> responsible folks have a high degree of certainty that
> their core links will pass the packets w/o loss due to
> an MTU restriction, or they just don't care that large
> packets are silently lost. So, it has to be the former
> since folks that just don't care don't stay in business.

Just to shed some current operational reality to this thread.  There are 
providers who are using 6PE as the means to transport IPv6 packets over a 
theoretically IPv4-only core/Backbone[1].  One of the chief design principles 
of 6PE is that those "IPv4-only" Core LSR's only know of IPv4 routes (and, IPv4 
routing) and do not have any knowledge/understanding of IPv6.  As such, if/when 
a Core LSR in a 6PE Backbone receives a IPv6/MPLS packet, i.e.: due to 
Hop-Limit expired or, in this case, the Core LSR considers it too big to 
label-switch out the outgoing interface ... the "simple", but ugly, answer is 
for the Core LSR to drop the IPv6/MPLS packet on the floor.  Fortunately, most 
providers should be clued in to this "limitation" of 6PE and (should) have Core 
links set to use [very] large Jumbo frames, thus working around the issue of 
needing Core LSR's to generate PTB's back to the source.  One potential 
workaround to the Hop-Limit issue is to use "TTL-hiding" on LSP's, but that
  tends to be frowned on by Operations folks and customers who rightfully want 
to be able to use traceroute and cut+paste output that shows where along a path 
something in broken ...

In short, 6PE *was* a decent stop-gap technology, but should be put out to 
pasture sooner rather than later.  Although dual-stack on Core devices is one 
answer, another one would be support for MPLS-signaling protocols (LDP & RSVP) 
that use native, IPv6 for Transport, which has kind of been on the back-burner 
-- although some of us have been trying to push it's development more and more.

-shane

[1] Reasons which were likely valid as of just a few years ago, but are no 
longer so.




> This current "pool pah" of FUD reminds me of the one
> that transpired at the 2002 v6ops interim meeting when
> the subject of tunnel MTU got started. Others may
> choose to repeat that, but I've personally seen enough
> of it for one lifetime.
> 
> Thanks - Fred
> 
>> I was referring to the latter, not the former.
>> My apologies for being unclear.
>> 
>> Yours,
>> 
>> Ran
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email protected]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to