[191773] in North American Network Operators' Group
Re: Request for comment -- BCP38
daemon@ATHENA.MIT.EDU (Florian Weimer)
Tue Sep 27 04:51:30 2016
X-Original-To: nanog@nanog.org
From: Florian Weimer <fw@deneb.enyo.de>
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Date: Tue, 27 Sep 2016 10:51:24 +0200
In-Reply-To: <52cdb2fe-ef51-a15a-d6a3-4cb55b0b3040@gmail.com> (Baldur
Norddahl's message of "Mon, 26 Sep 2016 22:08:36 +0200")
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
* Baldur Norddahl:
> This means we can receive some packet on transit port A and then route out
>>> a ICMP response on port B using the interface address from port A. But
>>> transit B filters this ICMP packet because it has a source address
>>> belonging to transit A.
>> Interesting. But this looks like a feature request for the router
>> vendor, and not like an issue with BCP 38 filtering as such.
>
> Can you quote an RFC for anything that the router is doing wrong? Is
> there a requirement that a router must support source routing?
It's not an RFC conformance issue (several implementations of source
address selection are possible). But it appears to make it rather
difficult to configure it in such a way it does what you need, and it
looks like a reasonable enhancement request.
> In our case we actually did contact the vendor. Turns out that it will
> do source routing but not for packets from the control plane. There is
> no way to resolve the issue with the current software available to
> us. The vendor is not priotizing fixing this as I am also unable to
> point to any RFC that is being violated.
Source routing is not required to fix this. Other options are using a
globally routed IP address for the source address (this can also be
used to conserve address space because the interface addresses will
not matter anymore), or chosing the interface address based on the
outgoing interface.
