Subject: v6 multihoming and route filters

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 28 Jun 2006 12:32:57 -0700

Hello-  I have reviewed Marc Banchets document on IP V6 Routing Policy Guidelines Filename:  draft-ietf-v6ops-routing-guidelines-00.txt

I am concerned that the current draft does not include detailed routing guidelines for multihoming.  This document does not include guidelines for multihoming in the current V6 routing framework. V6 can be used identically like V4 to do multihoming and this is what I would like to do with V6. 

I currently have customers asking for this ability and none of them wish to wait for solutions that may not be fully developed for a couple more years.  Also, my customers don't want to get PI space (even under the new V6 PI policy), so this means I need to give them a /48 and set up multihoming.  However, as all policy and practices sit right now, everyone filters on a /32.

I ask the V6 WG to create a "best practice for multihoming" that can be utilized today.  I ask that you please insert the solution to filter at /48 thus allowing "upstream providers" to provide multihoming to their customers.  This solution is needed to support providers creating V6 networks and this solution can easily be added into Marc's "IP V6 Routing Policy Guidelines" document. 

Thank you for your time
Marla Azinger
IP Engineering
Frontier Communications

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Jun 2006 07:45:13 +0300 (EEST)

On Wed, 28 Jun 2006, Azinger, Marla wrote:
> I ask the V6 WG to create a "best practice for multihoming" that can 
> be utilized today.  I ask that you please insert the solution to 
> filter at /48 thus allowing "upstream providers" to provide 
> multihoming to their customers.  This solution is needed to support 
> providers creating V6 networks and this solution can easily be added 
> into Marc's "IP V6 Routing Policy Guidelines" document.

This is unlikely to get traction in the WG.  The initial draft was 
basically like that but was changed. Many people (myself included) 
opposed (and will oppose) recommeding opening filters up to /48.

Let's not create a swamp out of v6 address space with more specific 
junk.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jun 2006 10:27:51 +0200

Pekka Savola wrote:
> Let's not create a swamp out of v6 address space with more specific junk.
> 

See RFC 4177 section 5.1:
   "This approach generally meets all the goals for multi-homing
    approaches with one notable exception: scaleability."

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 1 Jul 2006 02:06:19 +0200

Marla,

On 28-jun-2006, at 21:32, Azinger, Marla wrote:

> I currently have customers asking for this ability and none of them  
> wish to wait for solutions that may not be fully developed for a  
> couple more years.  Also, my customers don't want to get PI space  
> (even under the new V6 PI policy), so this means I need to give  
> them a /48 and set up multihoming.  However, as all policy and  
> practices sit right now, everyone filters on a /32.

I see there is a long discussion on ppml that I hadn't noticed before  
about this subject. Scott Leibrand made some good points on both the  
usefulness and the limitations of multihoming using PA space. It's  
too bad that some others are pushing for PI. PI ALWAYS needs a place  
in the global routing table, while with shooting holes in PA, the  
more specific only needs to be visible in part of the network. As  
long as that part is big enough to provide reasonable multihoming  
benefits, this works out well of all parties involved.

Unlike PI, PA multihoming is compatible with what we're trying to do  
in shim6, which may or may not be an advantage, but it can't hurt.  
(If anyone has questions about shim6, email me off-list.)

Thinking in practical terms, I don't see an "allow all /48s" policy  
adopted by most network operators any time soon, as it commits them  
to something that may not give them trouble now, but has the  
potential to do so in the future. An alternative would be to come up  
with a BGP community to tag /48s that are used in multihoming so that  
it's possible to selectively allow those while still rejecting /48s  
that are deaggregated by accident. It will probably still take some  
time to get this adopted, but ISPs are smart enough to realize that  
more multihoming is more business for everyone, so I expect that  
something like this will be accepted unless there are problems that  
make this solution unattractive. I would be happy to co-author a  
document outlining this.