[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
David Conrad wrote:
> Paul,
>
> On Apr 29, 2010, at 8:29 AM, Paul Timmins wrote:
>
>> If you change ISPs, send out an RA with the new addresses, wait a bit, then send out an RA with lifetime 0 on the old address.
>>
>
> Even if this works (and I know a lot of applications that use the socket() API that effectively cache the address returned by DNS for the lifetime of the application), how does this help situations where IPv6 address literals are specified in configuration files, e.g., resolv.conf, glue for authoritative DNS servers, firewalls/filters, network management systems, etc.? See sections 5 and 7 of http://www.rfc-editor.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt
>
> The point here is that if there is a non-zero cost associated with renumbering, there will be non-zero incentive to deploy technologies such as NATv6 to reduce that cost. Some folks have made the argument that for sites large enough for the cost of renumbering to be significant, they should be able to justify provider independent space and be willing to accept the administrative and financial cost. While this may be the case (I have some doubts that many of the folks using PA space now will be all that interested in dealing with the RIR system, but I may be biased), it does raise concerns about routing system growth and forces ISPs to be willing to accept long IPv6 prefixes from end users (which some ISPs have already said they won't do).
>
Put your recursors, network management systems, fileservers, etc on ULA
addresses like I was talking about earlier. Then you don't have to
renumber those.
So the only change you should have to make is a firewall change.
Imagine a world with RFC-1918 and public ip space safely overlayed. For
anything you hardcode somewhere, unless it has to be publically
reachable, use ULA addresses and don't ever change them.
You could even choose to not have public IP space on your servers by
removing autoconf, though you could have public space on them so they
can apply updates, and simply block any inbound access to those
statefully with a firewall to prevent any outside risk.
-Paul
- References:
- Rate of growth on IPv6 not fast enough?
- From: johnl at iecc.com (John Levine)
- Rate of growth on IPv6 not fast enough?
- From: owen at delong.com (Owen DeLong)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: johnl at iecc.com (John R. Levine)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: andy at nosignal.org (Andy Davidson)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: davei at otd.com (Dave Israel)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: matthew at matthew.at (Matthew Kaufman)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: crosevear at skytap.com (Carl Rosevear)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: drc at virtualized.org (David Conrad)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: paul at telcodata.us (Paul Timmins)
- the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
- From: drc at virtualized.org (David Conrad)