200 likes | 318 Views
IPv6 Site-Local Discussion. Bob Hinden & Margaret Wasserman IETF 56 San Francisco March 2003. Goals for Site-Local Discussion. Analyze options available for site-local usage and reach consensus on an approach
E N D
IPv6 Site-Local Discussion Bob Hinden & Margaret Wasserman IETF 56 San Francisco March 2003
Goals for Site-Local Discussion • Analyze options available for site-local usage and reach consensus on an approach • Chairs both believe that it is more important to make a decision and move forward than it is to pursue any particular approach • Chairs will both support any proposal that reaches WG consensus
Range of Use Cases • No site-local addresses • Only on disconnected networks (“limited”) • Nodes exclusively global or site-local • Nodes do not have both global & SL addresses • No multi-sited nodes (“moderate”) • A node may be in, at most, one site • Full usage, including site-border nodes
Current Documents • “Limited” usage document in SL impact appendix • “Exclusive” model is not documented • “Moderate” usage proposal • “Full” usage documented in scoped addressing architecture (WG I-D) • Site local impact draft documents issues with “full” usage -- no longer directly applicable • Already have WG consensus not to support
“Limited” Model • Site-locals used only on disconnected sites • Non-Internet connected sites • Sites behind NAT • IPv4<=>IPv6, IPv6<=>IPv6 • Site-locals treated exactly like globals • Transition from disconnected to connected requires renumbering
“Exclusive” Model • Site-local and global addresses are never configured on the same node • Nodes must be explicitly configured to use site-locals • Simplifies address selection • Use what you have • Specifies rules for simple SBRs and firewalls to enforce site boundaries • Requires “no site” concept, similar to “moderate” proposal • Site-local addresses not in global DNS • Eliminates possibility of hosts leaking site-locals globally
“Moderate” Model • Site-local addresses must be explicitly configured • In Router Advertisements and DNS • Nodes may have site-local and/or global addresses • No requirement for nodes to be multi-sited • Specifies rules for simple SBRs and firewalls to enforce site boundaries • Introduces “no site” concept • No routing protocol changes required • Prefer global over site-local in address selection • Site-local addresses not in global DNS • Only create site-local address using Autoconf or Privacy
“Limited” Model Benefits • Addressing for disconnected sites • Addressing behind NATs
“Exclusive” Model Benefits • “Limited” model benefits, plus: • Stable addressing for local nodes • Global nodes do not have stable addresses in newly connected, intermittently connected or renumbered networks • Connections between local nodes survive address prefix changes • Prevents global access to/from local nodes and services
“Moderate” Model Benefits • “Exclusive” model benefits, plus: • Stable addressing • Site-local addresses remain stable in newly connected, intermittently connected or renumbered networks • Potential for applications to choose site-local addressing to allow local connections to survive address prefix changes
Issues List • IP Layer Address Leaking • DNS Address Leaking • Address Leaking by Upper-Layers • Routing Protocol Issues • Forwarding Table Issues • Mobile IP Issues
IP Layer Address Leaking • Site-local IP source/destination addresses leaking outside of the site • None of the proposals have this problem • “Limited” proposal doesn’t send packets outside the site (isolated) • “Exclusive” and “Moderate” enforce at site boundaries
IP Address Selection Issues • Changes required to existing IPv6 address selection rules and implementations • “Limited” and “Exclusive” do not require changes • “Moderate” requires change to prefer global over site-local
DNS Address Leaking • Need to keep site-local addresses out of the global DNS • “Limited” proposal doesn’t have this problem because there is no global DNS access • “Exlusive” and “Moderate” require some mechanism to enforce (i. e. split DNS)
Address Leaking by Upper-Layers • Addresses leaked by application, session and transport layer protocols that exchange addresses with other nodes • “Limited” doesn’t have problem • “Exclusive” eliminates problem because global nodes don’t have local addresses to leak • “Moderate” requires upper layers to have address selection rules
Routing Protocol Issues • Routing protocols shouldn’t exchange site-local routes across site boundaries • All of the proposals eliminate this problem • “Limited” doesn’t connect to outside routers • “Exclusive” and “Moderate” introduce “no site” concept at site borders and BGP filters
Forwarding Table Issues • Need to maintain multiple site-local forwarding table and select between them • All proposals eliminate this problem • None support nodes in more than one site
Mobile IP Issues • Nodes may move between sites • Site local addresses from the first site are not valid (and may be ambiguous) in the new site • “Limited” doesn’t have problem • “Exclusive” and “Moderate” requires mobile nodes to use only global addresses
Major Differences • Differences between “Exclusive” and “Moderate”: • “Exclusive” does not require address selection in upper-layer protocols nor at IP layer • “Exclusive” does not require changes to IPv6 address selection rules and implementations • “Limited” proposal eliminate all issues and virtually all benefits
Moving Forward • Can we reach consensus on an approach to pursue? • Do we have enough information to decide? • “Limited”, “Exclusive” or “Moderate” • If not, can we progress parts of Scoped Addressing Architecture without site-local? • Multicast and link-local