Subject: Newbie Question about addressing impacts

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 11 Aug 2004 09:13:46 -0700

Newbie question: Assuming a multihomed environment with N ISPs supporting a corporate network of 2K+ routers and 200K+ computers. Is multi6 proposing that the interfaces of the routers and computers each have N different global addresses, one set for each of the N ISPs? If so, has multi6 considered the impact of this approach to IGP and EGP performance? If so, what was the consensus conclusion to that evaluation?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Aug 2004 19:36:33 +0200

Hi Eric,

On 11-aug-04, at 18:13, Fleischman, Eric wrote:

> Newbie question: Assuming a multihomed environment with N ISPs 
> supporting a corporate network of 2K+ routers and 200K+ computers. Is 
> multi6 proposing that the interfaces of the routers and computers each 
> have N different global addresses, one set for each of the N ISPs?

At this time, multi6 isn't exactly proposing anything. But yes, pretty 
much everything that's under discussion right now assumes this.

> If so, has multi6 considered the impact of this approach to IGP and 
> EGP performance? If so, what was the consensus conclusion to that 
> evaluation?

There hasn't been an evaluation.

There is a feature that I'm very much in favor of that could help here: 
the ability to implement a multihoming solution in middleboxes or 
border routers. In such a scenario, there would be a set of addresses 
for internal use in the site, and the proxy multihoming devices add the 
multihoming capability somewhere close to the border of the network. 
The good thing here is that there is no need to modify each individual 
host to obtain multihoming benefits, and it's easier to implement 
policy in a few central places rather than distributed over all the 
hosts in the network.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Aug 2004 20:47:23 +0300 (EEST)

> much everything that's under discussion right now assumes this.

I think pretty much everyone has silently made an assumption that it
would be unreasonable to expect that to happen -- especially if all
the hosts would need to be globally addressable (and not e.g. with
unique local addresses, with global addresses only distributed to the
proxy servers or whatever).

The really big folks WILL get their own /32 allocation in some way or
the other, I'd guess.  I'm not so opposed to the idea.. just the fact
that if that becomes a common practice, it'll be difficult to draw the
line in RIR policies..

This is probably the case for very big enterprises who have a limited
number of ISPs and Internet connection points, possibly in the same
region (i.e.: all the traffic goes through 2-3 ISPs).

It's slightly different if you have 100 branch offices in 100
different countries: then addressing each country's offices from each
country's ISP provider address space might still be feasible.

-- 
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: Tony Li <[email-masked]>
Date: Wed, 11 Aug 2004 17:16:32 -0700

> There is a feature that I'm very much in favor of that could help 
> here: the ability to implement a multihoming solution in middleboxes 
> or border routers. In such a scenario, there would be a set of 
> addresses for internal use in the site, and the proxy multihoming 
> devices add the multihoming capability somewhere close to the border 
> of the network. The good thing here is that there is no need to modify 
> each individual host to obtain multihoming benefits, and it's easier 
> to implement policy in a few central places rather than distributed 
> over all the hosts in the network.
>

Architecturally, this is the right thing to do.  However, it is an 
implicit validation of NAT, and if NAT's ok,
then why do we need v6 in the first place?

Ideally, in an Internet architecture that we don't have today, there 
would be N prefixes, one per ISP.  However, the host
portion of the locator would be a constant regardless of prefix.  The 
IGP need not know about the external prefixes, so there's
no issue there.  The EGP is not impacted because each of the prefixes 
is out of the respective SP's aggregate.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Aug 2004 10:58:56 +0200

El 11/08/2004, a las 19:36, Iljitsch van Beijnum escribió:

>> multi6 proposing that the interfaces of the routers and computers 
>> each have N different global addresses, one set for each of the N 
>> ISPs?
>

Well, even if you do a per host locator selection you can still manage 
policy in a centralized fashion, if we define proper mechanisms to 
perform policy distribution, for instance a dhcp option for 
distributing RFC3484 policy table or something similar. However, i 
don't know how you can enforce policy in a centralized manner when 
locator selection is performed by the end hosts.

anyway, i agree that proxys are attractive, especially for supporting 
advanced features like session survivability in legacy hosts

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Aug 2004 11:00:15 +0200

El 12/08/2004, a las 2:16, Tony Li escribió:

>> of the network. The good thing here is that there is no need to 
>> modify each individual host to obtain multihoming benefits, and it's 
>> easier to implement policy in a few central places rather than 
>> distributed over all the hosts in the network.
>>
>
>
> no issue there.

Good point.

But this implies modifying IGPs, right?

regards, marcelo

>   The EGP is not impacted because each of the prefixes is out of the 
> respective SP's aggregate.
>
> Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Aug 2004 03:12:39 -0700

> But this implies modifying IGPs, right?

Not seriously.  You would be modifying them to carry around a constant 
local portion of the address and ignore the "global"
prefix.  Simply picking a single constant prefix for use internally 
would suffice.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Aug 2004 12:47:53 +0200

El 12/08/2004, a las 12:12, Tony Li escribió:

>>> portion of the locator would be a constant regardless of prefix.  
>>> The IGP need not know about the external prefixes, so there's
>>> no issue there.
>>
>> Good point.
>>

so are you assuming that hosts within the multihomed site are not aware 
of their own global prefixes, so they only use this local prefix and 
that global prefixes are stuffed by exit routers "a la" GSE?

I was more thinking in that hosts are aware of their own global 
prefixes and that they use them within the site, but intr site routers 
know which are the local prefixes, so when the see a destination 
address that contains one of them, it just ignores the global part 
(/48) and just routes according to the bits between the /48 and the 
/64.
this implies that router have to know which are the global prefixes 
assigned to the site and for that case route based on the subnet bits.
(that is why i thought that some change to the intra site routing was 
needed)
regards, marcelo

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 12 Aug 2004 23:07:30 +0900

Oops, I forgot to send CC to multi6.

--
Hi marcelo,

> locator selection is performed by the end hosts.

I believe that such a mechanism for policy distribution
is really important. By making use of the existing RFC3484
framework, IMHO we can develop much manageable multi-home
environment in a simple and easy manner.

Now I'm working on this mechanism to publish a new I-D.
But I'm not sure such kind of topic is appropriate for
this WG or not. I believe this part of the technology should
be necessary for some of the proposals discussed here, though.

--
Arifumi Matsumoto
     Ubiquitous Computing Project
     NTT Information Sharing Platform Laboratories
     E-mail: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Aug 2004 16:16:40 +0200

> prefix.  Simply picking a single constant prefix for use internally 

Hence draft-ietf-ipv6-unique-local-addr-05.txt

I'd also like to observe that running with multiple simultaneous
prefixes (with its consequences for DNS and routing) has always
been part of IPv6; it's not a result of hypothetical multi6 solutions.

I also tend to agree that very large enterprises (such as I and Eric
happen to work for) may be best served by simply getting a /32, but
there are many medium size enterprises for which this is not true,
and that is exactly why we are running this WG.

     Brian

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Aug 2004 16:26:46 +0200

One of the components we have already identified (see the minutes
from San Diego) is

  Locator selection after a failure has been detected / Choose new address pair

RFC 3484 policy distribution might be a possible solution
for that component. We aren't chartered to do basic design in
this WG, but it would certainly be good to see proof-of-concept
for this (and every) component.

      Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Aug 2004 13:22:49 +0200

Hi Brian, Arifumi,

I am not sure that the policy table falls under this particular 
component, since as i see it, the policy table is more related with 
locator selection when there are no failures and it is used as a mean 
to express administrative prefferences.
Anyway, as i understand it, Arifumi is considering mechanisms to 
distribute RFC3484 policy table, so this is not really related to 
locator selection, but rather with centralized policy management.
IMHO this will be a requirement, especially as the sites grow bigger, 
because manually configuring the policy table of each hosts doesn't 
seems a reasonable approach when there is a considerable number of 
hosts.
Well, in any case, i can see basically two options to provide automatic 
configuration of RFC3484 policy table:
- router Advertisement
- dhcp option

the porblem with RA is that the full policy table has to fit in a 
single RA message, since imho the distribution of the policy table 
should be atomic (having only part of the policy table configure may 
cause undesired behaviour), in addition, RA requires the configuration 
of the policy table in at least one router per link, which may be 
cumbersome
the problem with dhcp is that you need a dhcp server, but it provides 
most of the desired features AFAICS

imho, a policy distribution mechanism will be needed at some moment.
We have made a couple of implementations in linux of the two policy 
table distribution mechanisms, one using dhcp and another one using RA, 
to see how this work.
If anyone is interested, we can discuss it.

Regards, marcelo

El 12/08/2004, a las 16:26, Brian E Carpenter escribió:

>>> Well, even if you do a per host locator selection you can still 
>>> manage policy in a centralized fashion, if we define proper 
>>> mechanisms to perform policy distribution, for instance a dhcp 
>>> option for distributing RFC3484 policy table or something similar. 
>>> However, i don't know how you can enforce policy in a centralized 
>>> manner when locator selection is performed by the end hosts.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2004 15:27:07 +0200

If I recall correctly, the policy table can list prefixes
explicitly in priority order. So for mh, than means that
policy can say: if A fails, try B; if B fails, try C.

But I may be misremembering 3484, it's been a while...

    Brian

marcelo bagnulo braun wrote:
> locator selection when there are no failures and it is used as a mean to 
> express administrative prefferences.
> seems a reasonable approach when there is a considerable number of hosts.
> the porblem with RA is that the full policy table has to fit in a single 
> RA message, since imho the distribution of the policy table should be 
> atomic (having only part of the policy table configure may cause 
> undesired behaviour), in addition, RA requires the configuration of the 
> policy table in at least one router per link, which may be cumbersome