(Loose) uRPF vs. non-announced IXP space

Stefan Neufeind v6ops at stefan-neufeind.de
Wed Feb 8 13:35:47 CET 2012


On 02/08/2012 01:12 PM, Gert Doering wrote:
> 
> On Wed, Feb 08, 2012 at 01:01:24PM +0100, Thomas Schmid wrote:
>> On 08.02.2012 12:55, Bernhard Schmidt wrote:
>>> FYI, I've been informed that there has been a similar problem on the
>>> RIPE ipv6-wg mailinglist last June. Start here:
>>>
>>> http://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html
>>>
>>> There has not been a clear solution in this thread either.
>>
>> that's a real pain, especially since IXPs are the internet's MTU 
>> bottlenecks.
> 
> Actually, if the *IXP* is the MTU bottleneck, this is not a problem
> at all - as the last router *before* the IXP would source the ICMP
> packet, and not the router after the IXP mesh.
> 
> In this case, it's the first router *after* the IXP, which sends
> back the ICMP packet using the IXP interface as egress, thus using
> the uRPF-filtered source address.
> 
>>  From my point of view RFC 5963 should be updated to recommend the 
>> global announcement
>> of IX prefixes for IPv6 or - as already mentioned - an alternative would 
>> be to source the
>> ICMP messages from a public address instead.
> 
> Vendors providing uRPF implementations that cannot be configured to
> add exceptions, like "permit all ICMP packet too big" are part of the
> problem.

Hi,

but why don't those routers source the ICMP-message from a
loopback-address or the like with an "official IP"?

And if you were to allow using ICMP from private network-ranges
altogether, then we could use link-local-addresses for peering with
neighbor-autodiscovery (just need to know the AS-number of your
neighbor) Oh wait, or configuring a wildcard for ASN so you'd peer with
everybody on that interface (and we could get rid of IPv6-routeservers).
Hehe ... just kidding :-)


Regards,
 Stefan



More information about the ipv6-ops mailing list