22 Apr
2018
22 Apr
'18
4:44 a.m.
Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why
would there be NAT?
On Sat, Apr 21, 2018 at 1:29 PM, Tony Langdon <vk3jed(a)vkradio.com> wrote:
> If all you're running are Echolink proxies and relays, sure, I get your
> argument, the issue of NAT at the source isn't a big deal and simply
> routing 44.190.0.0/16 via the NAT router at each end user is a good
> solution, but for those of us who WANT to do something more than merely run
> proxies on those addresses, I'd like to be able to get my routing right, so
> NAT doesn't bite me in the bum when I attempt to set something else up.
>
> On Sat, Apr 21, 2018 at 11:57 PM, Kenneth Finnegan <
> kennethfinnegan2007(a)gmail.com> wrote:
>
> > On Sat, Apr 21, 2018 at 4:51 AM, Tony Langdon <vk3jed(a)vkradio.com>
> wrote:
> > >
> > > The problem I have with this is when traffic is routed via the regular
> > > ISP, the source address is no longer 44.x, it's the public IP of the
> NAT
> > > router.
> >
> >
> > Why should I as an Echolink relay operator be expected to go through the
> > additional effort of configuring IPIP just so you can enjoy the novelty
> of
> > both ends of the connection having 44/8 addresses? Your IPIP encapsulated
> > packet will still have your ISP's address and will take the same path
> > regardless. I understood that one of the motivations of the 44.190/16
> > prefix was to allow end users to easily configure their routing policy
> > correctly to avoid tunneling to UCSD first (which isn't the end of the
> > world since Javier and I are setting up our relays also in California).
> >
> > --
> > Kenneth Finnegan
> > http://blog.thelifeofkenneth.com/
> >