On Sunday, January 02, 2011 05:40:00 pm Genes MailLists wrote:
>    How does one manage your internal ip6 network so that an ISP change
> (which under NAT/ipv4 is irrelevant) - is straightforward/clean to manage ?

Somehow I missed this message that started the whole thread... Shame on me.

There as several ways, some of which have been mentioned.

The one I'll mention is using the combination of provider-assigned (PA) IPv6 
addresses on the outside with unique-local addresses (ULA; see RFC 4193) on the 
inside and one to one NAT66 in between ( see 
http://tools.ietf.org/html/draft-mrw-behave-nat66-02 for the draft for NAT66 at 
the IETF).  

A Linux ip6tables extension project to do this can be found at 
http://map66.sourceforge.net/

Unlike many, I see NAT as not primarily a security tool but as an end-user 
flexibility tool that keeps the end-user from ever having to renumber anything, 
as well as do sane internal addressing and subnetting.  With IPv4 one inside 
global address to many inside local addresses (those are Cisco NAT's terms, as 
there are also outside global and outside local addresses that can be NATted) 
is the normal use-case; this isn't needed for IPv6, but an end user is not 
going to want to renumber the inside network when switching providers.  
Renumbering, even servers with DNS, is a pain, especially thanks to some DNS 
caches not honoring TTL.

The alternative of running your own autonomous system (AS), running border 
gateway protocol (BGP), and getting your own provider-independent (PI) address 
space is not at all palatable to the ISP community (route table bloat due to 
prefix deaggregation); the only really valid case for PI space is multihoming, 
from an ISP and RIR/LIR perspective, in which case you'll already be an AS and 
running BGP to get the benefits of multihoming.
-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Reply via email to