Operational challenges of no NAT

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Sun Oct 31 10:58:38 CET 2010


On Sat, 30 Oct 2010 23:18:57 -0700
"George Bonser" <gbonser at seven.com> wrote:

> > 
> > With IPv6, you can have individual addresses per *application* - if
> you
> > move that application to another host within the subnet you move the
> > address along with it. 
> 
> That is actually the plan, but you need to add the IP to the box.  If we
> were using something like dhcp, it might be easier but these things need
> to work even if the dhcp server isn't working correctly.  The kernel
> modifications in that paper aren't an option for several reasons, the
> primary reason being we use a different operating system.
> 
> 
> > And if you want even more agility, you could
> > have the application specific IPv6 address injected into your routing
> > domain as a host route - i.e. anycast without the multiple
> > application instances. For your scenario you'd reserve a /64 for all
> > your application specific addresses, and then tell your partners to
> > white list only this /64.
> 
> 
> 
> > "Transient addressing for related processes: Improved firewalling by
> > using IPv6 and multiple addresses per host"
> > http://www.cs.columbia.edu/~smb/papers/tarp.pdf
> > 
> > Isn't it magic how "too much" IPv6 address space and large subnets
> > allows you to do things that are impossible to do in IPv4.
> 
> This really addresses a different problem than the one I meant to
> describe.  I need an application bolted to one address forever.  Then I
> need a different instance of that same application on the same machine
> bolted to another unique address on the same machine.  That is not a
> problem.  Now I tell foo.com what the two IPs are.  One is for Jones,
> one is for Smith.  Now I roll out another instance for Jones.  I need to
> tell foo.com to add another IP to their throttling configuration.  
> 
> It is just easier to put all Jones IPs in one subnet and all Smith IPs
> in a different subnet and tell foo.com that anything they see from
> subnet 1 is on behalf of Jones and anything they see from subnet 2 is on
> behalf of Smith.  But they have been reluctant to configure subnets,
> they have wanted to do only specific IPs which wasn't a problem with v4
> because I could put them all behind a NAT.  Note that this isn't for
> firewalling, this is a server  configuration on their side where they
> keep track of statistics of transactions for Smith and Jones and set a
> maximum transaction rate limit that might be different for the two.
> 

So the granularity of their checking was at the IP address level only?
Application sockets, which are the identifier for networked
applications, are a combination of an IP address and a port number. If
the granularity of checking is at the IP address level, then they're in
effect permitting traffic from any of 65K remote sockets.

Why don't they want to configure subnets? As you've said this isn't
about security, there are no issues about theoretically too much (i.e.
subnets) or too little access (individual host addresses). Operational
simplicity doesn't justify it either - permitting a range of addresses
(i.e. a subnet) is operationally simpler, rather than forcing the remote
party to use NAT to hide behind an IP address, and then have sockets
create unique remote application identifiers. They're actually choosing
to lose a level of remote identification granularity because they're
forcing you to hide multiple machines behind NAT - or don't they know
your doing that (well, they'd only know if you'd told them ...).

> They will come around to subnets because it is going to be impossible
> for them internally to handled individual IPs unless they somehow
> automate that configuration where maybe a host could "register" itself.
> 

If they're uncomfortable with trusting you to assign 2^64 IPv6
remote addresses (i.e. a /64 of yours that they've configured), but are
currently comfortable with trusting you to assign 2^16 (TCP) remote
ports (of course, this app might run over UDP, and/or they might not
care about the transport layer protocol, so it may be at least 128K
ports), get them to trust you with 2^16 IPv6 addresses from within
a /64, and say that you'll statically assign them e.g. ::1 -> ::ffff. I
don't think that is entirely rational solution, but then again I don't
think they're being very rational about what they're currently doing
either.



More information about the ipv6-ops mailing list