Operational challenges of no NAT

Ben Jencks ben at bjencks.net
Thu Oct 28 12:01:33 CEST 2010

On Thu, Oct 28, 2010 at 02:31, George Bonser <gbonser at seven.com> wrote:
> Now I must get each one of these servers individually white listed and
> if an IP changes, that must be changed at the other end too.  And it can
> sometimes take weeks to get things white listed depending on who it is
> with.  I have people who balk at white listing a /25 as being too wide a
> range.  What are they going to think about a v6 /64?  This also prevents
> any use of autoconfiguration if each address must be separately white
> listed.  Most of these accesses are stuff that the regular internet has
> access to but we are allowed a greater number of accesses without being
> throttled or there might be considerable configuration involved where a
> certain function in one direction has a "call back" IP that is
> different.  So each IP that we might connect into them with must be
> mapped to some other IP on our side for transactions from them that
> might happen later.

Wouldn't crypto, either HMAC or signatures, be a better assurance of
authorization? Sure, they can whitelist your /64, but that just serves
to keep the riff-raff out; the signature provides the actual identity

For callbacks, they should be done with DNS names. That way you're
v4/v6 agnostic at the application layer, and you can renumber your
callback receiver at will.

I'm aware that in dealing with big providers they can have a pretty
hard-to-budge idea of how to do things. But if you're asking for the
"IPv6 way", I think crypto and DNS are the way to go.


More information about the ipv6-ops mailing list