|
(To v6ops only). I think that there are three distinct issues: 1. Source address selection for outbound communications, 2. Path specification and robustness for inbound communications (which subsumes destination address selection and routing specification) 3. Source address and path independent communications. For each of these: 1: is well described in RFC5220 3: is being handled by SHIM6 and similar approaches, but aren't strictly required for multihoming (but are interesting nevertheless). 2: can be handled either by specification of the routing path or destination address. The current APNIC(pick a NIC) etc rules which allow provider independent IPv6 address allocations to existing IPv4 MH customers seem sensible enough for the early adopters who already have the BGP policy nous to manage the routing. Proliferation of Provider Independent addressing is problematic though, in that there's the potential for unrestricted growth in the routing table (this was problematic before when memory was expensive and helped motivate the IPv6 architecture, but we have a potentially much larger Internet in the future, and we do not know how things will develop). I prefer that the ultimate solution doesn't require every multihomed PAN to have a PI prefix (for example). I am interested in exploring other mechanisms, like DNS based specification of service addresses (with failover and load balancing policies). This provides multiple destination addresses, but leaves backbone routing largely to the core ISPs, but leaves the specification of how services are reachable to the content provider (where arguably it belongs). An initial experimental approach which attempts this is shown in: http://www.ietf.org/id/draft-daley-dnsext-host-srv-00.txt Sorry to tootle my own trumpet, but hey ;) Greg Date: Mon, 25 Jan 2010 10:55:42 +0200 Subject: IPv6 multihoming From: vlad.thoth@gmail.com To: shim6@ietf.org; v6ops@ops.ietf.org Hi, For a year now whenever it comes to IPv6 telco implementations I keep facing 2 problems so I was hoping you can guide me towards find a group that deals with these issues or discussion solutions. The 2 problems are related to IPv6 multi-homing and access to the internet in IPv6 format for a quick transitions from v4 to v6. Also I need some guidance as to what needs to be done for a draft document proposal to be created about the proposed solutions mentioned bellow and who needs to be involved in this process. As far as multi-homing goes in IPv6 the solution discussion generated by using provider-independent address space like mentioned in draft-hain-ipv6-pi-addr-10 seems too complicated to implement efficiently and generates a lot of unnecessary work. Because IPv6 will never really be adopted by ISPs, telco and enterprises until it offers a feasible multi-homing solution my proposal is that some solutions are redefined such as provider independent address space and the 6to4 standard. I propose that the 6to4 ip conversion space from ipv4 addresses to 2002::ipv6 space will be redefined as provider independent address space. This way whoever wants to implement ipv6 with multi-homing can simply redefine their existing IPv4 addresses in IPv6 6to4 format and have multi-homing in ipv6. Everyone already uses ipv4 multi-homing with success so I see no point in defining a new addressing system for v6 when everyone can simply use the same v4 address space for multi-homing but converted in 6to4 format. Also, another issue faced by whoever uses IPv6 is that access to the internet in v6 format is limited so a proposal has to be made to the RIRs to offer incentives such as free IPv6 space for anyone who implements 6to4 relay routers and advertises their existing v4 space in v6 format along with the newly received free v6 space. I believe that as long as ietf gets involved and a rfc is written on these 2 proposals starting with the redefining of the provider independent address space and its inclusion in the 6to4 format things will be a lot more compact and give some additional momentum to the IPv6 migration process. Best regards and I hope to hear from you soon, Vlad Ion Siemens PSE IP backbone design engineer Browse profiles for FREE View photos of singles in your area! |