Subject: ps & req in multi-prefix-env

From: Ruri Hiromi <[email-masked]>
Date: Tue, 3 Apr 2007 18:26:38 +0900

Hello,

For WGLC, I would like to confirm the description about "multi- 
interface" issue.

In the documents(http://www1.tools.ietf.org/html/draft-ietf-v6ops- 
addr-select-req-01) at section4(3) and (4), we wrote about comments  
given at IETF67.

(1) should or must?
  In our original requirement, we thought multi-prefixes with single  
interface.  Now we inserted  the additional description about the  
problems(s) to be considered at the situation of multi-prefixes with  
multi-interfaces.  My question here is; which is better to declare  
"the multiple interface issue SHOULD be considered?" and "the  
multiple interface issue MUST be considered?"?   which phrase is  
suitable?

(2) how? any ideas? references?
  If you already have an idea to solve this, could you feed us details?

====
(current description)
3) Issues that need big RFC 3484 change.
     - Multiple Interfaces Issues

       Dave Thaler gave us comments that multiple-interface hosts may
       face policy collision and distribution of dst address selection
       policy and src address selection policy should be separated.
       Also, per-interface policy table was proposed.

       After all, this is a policy collision problem.  To make a host
       have one policy table per network interface doesn't solve policy
       collision issue.  Source address selection is performed after
       output interface is selected, but destination address  
selection is
       before output interface selection.  In this case, destination
       address selection uses all the policy tables a host has, so here
       collision can happen.
       Separating destination address selection and source address
       selection will have a big change on RFC3484 policy table
       definition.  Though it may be a good idea to avoid source address
       selection policy collision.
====

Thanks in advance,
-------------------------------
Ruri Hiromi
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Apr 2007 11:44:07 -0700

On Apr 3, 2007, at 2:26 AM, Ruri Hiromi wrote:

> problems(s) to be considered at the situation of multi-prefixes  
> with multi-interfaces.  My question here is; which is better to  
> declare "the multiple interface issue SHOULD be considered?" and  
> "the multiple interface issue MUST be considered?"?   which phrase  
> is suitable?

I'm a little uncomfortable with the distinction in this context. The  
way I use the terms, which dates from the development and editing of  
what we now call RFC 1812, "MUST" implies that something breaks if  
you don't do it, while "SHOULD" implies that there may be cases in  
which it is valid to not do the action - and the implementation that  
doesn't do the "should" is on the hook to make that case.

For example an IP router MUST apply a longest-match-first lookup to  
determine what route entry to use - if it doesn't, it will send  
packets the wrong way. On the other hand, while it is legal and  
sensible to configure IP prefixes in terms of a prefix length, at the  
time that RFC 1812 was written it was common practice to use subnet  
masks and to not require that they be contiguous (eg expressible as a  
length). In the context of the era, the statement

    The <Subnet-number> bits SHOULD be contiguous and fall between the
    <Network-number> and the <Host-number> fields.  More up to date
    protocols do not refer to a subnet mask, but to a prefix length; the
    "prefix" portion of an address is that which would be selected by a
    subnet mask whose most significant bits are all ones and the rest  
are
    zeroes.  The length of the prefix equals the number of ones in the
    subnet mask.  This document assumes that all subnet masks are
    expressible as prefix lengths.

made sense. There were other ways to do things that we were in fact  
trying to stamp out, and have a decade later succeeded in stamping out.

In this context, the authors have argued that they are dealing with a  
special case network and system rather than the general case. In the  
general case, multi-LAN servers are pretty common, and multihomed  
networks with multiple DMZs are pretty common among the Fortune 1000  
list of companies. In the specific case of a home or a cube farm,  
single-interfaced hosts predominate by a huge percentage, and among  
non-fortune-1000 companies single homing and single-DMZ multihoming  
are pretty common. So I struggle with the question "who is your  
target audience". The people most likely to use your solution sound  
to me like the parties that you say you're not addressing.

In that context, what breaks if you don't address the multi-LAN  
server case? I think what "breaks" is that the administrators of  
those systems won't find your solution adequate, something you have  
already said you are perhaps OK with.

>  If you already have an idea to solve this, could you feed us details?

Goodness. To my admittedly small mind, the multiple-prefixes-on-one- 
interface case is a special case of multiple-prefixes-on-many- 
interfaces. Solve the latter and the former should fall out.

This is why I urged that you consider asking the network about  
destination address choice in some way. Since the host doesn't know  
the details of routing, it has two choices: to ask the network, which  
does, or to perform its own measurements and maintain some degree of  
memory in cache form.

---

From: "haofeng Zhang" <[email-masked]>
Date: Fri, 6 Apr 2007 11:10:48 +0800

Ruri,

Comment on section 4, 3), I quote,

      output interface is selected, but destination address selection is

I think, it depends for the source address selection and output interface
selection. When a host recieves a packet from one of its interface, it
supposed
to send back the response packet from the same interface. In this case, the
source address selection and output interface selection is done at the same
time.
The host just uses the destination address of the incoming packet as the
source,
and sends out from the same interface as the packet comes.
For the packets a host originates, it selects the source address first,
according to
the policy table defined in RFc3484. Once the source address selection is
done, the
outing going interface is selection accordingly.

Corrent me if I am wrong.

Zhang Haofeng
2007-4-6

---

From: Ruri Hiromi <[email-masked]>
Date: Wed, 11 Apr 2007 16:11:03 +0900

Hello,

Thanks for the advise, from my understanding of what you mention  
about, I will wipe out my bad assumption and break my shackles.
So that we address all possible cases includes multi-LAN services.

> the details of routing, it has two choices: to ask the network,  
> which does, or to perform its own measurements and maintain some  
> degree of memory in cache form.

I prefer the former idea because reflection of some dynamics of outer  
network will be needed in some cases(i.e. network modification) but I  
still wonder to-comply-with-routing or having-local-calculation- 
method will solve "conflict problem in policy table"?
Is there still some consideration points?

Regards,

On 2007/04/04, at 3:44, Fred Baker wrote:

>> addr-select-req-01) at section4(3) and (4), we wrote about  
>> comments given at IETF67.
>>
>> (1) should or must?
>>  In our original requirement, we thought multi-prefixes with  
>> single interface.  Now we inserted  the additional description  
>> about the problems(s) to be considered at the situation of multi- 
>> prefixes with multi-interfaces.  My question here is; which is  
>> better to declare "the multiple interface issue SHOULD be  
>> considered?" and "the multiple interface issue MUST be  
>> considered?"?   which phrase is suitable?
>
> I'm a little uncomfortable with the distinction in this context.  
> The way I use the terms, which dates from the development and  
> editing of what we now call RFC 1812, "MUST" implies that something  
> breaks if you don't do it, while "SHOULD" implies that there may be  
> cases in which it is valid to not do the action - and the  
> implementation that doesn't do the "should" is on the hook to make  
> that case.
>
> sensible to configure IP prefixes in terms of a prefix length, at  
> the time that RFC 1812 was written it was common practice to use  
> subnet masks and to not require that they be contiguous (eg  
> expressible as a length). In the context of the era, the statement
>
>    subnet mask whose most significant bits are all ones and the  
> rest are
> In this context, the authors have argued that they are dealing with  
> a special case network and system rather than the general case. In  
> the general case, multi-LAN servers are pretty common, and  
> multihomed networks with multiple DMZs are pretty common among the  
> Fortune 1000 list of companies. In the specific case of a home or a  
> cube farm, single-interfaced hosts predominate by a huge  
> percentage, and among non-fortune-1000 companies single homing and  
> single-DMZ multihoming are pretty common. So I struggle with the  
> question "who is your target audience". The people most likely to  
> use your solution sound to me like the parties that you say you're  
> not addressing.
>
> the details of routing, it has two choices: to ask the network,  
> which does, or to perform its own measurements and maintain some  
> degree of memory in cache form.
>
>> ====
>> (current description)

---

From: Ruri Hiromi <[email-masked]>
Date: Wed, 11 Apr 2007 16:20:59 +0900

We have also recognized this problematic case for "ordering" but not  
mentioned about it.
Reflect this to the problems statement.

Thanks you!

On 2007/04/06, at 12:10, haofeng Zhang wrote:

> selection. When a host recieves a packet from one of its interface,  
> it supposed
> source address selection and output interface selection is done at  
> the same time.
> The host just uses the destination address of the incoming packet  
> as the source,
> For the packets a host originates, it selects the source address  
> first, according to
> the policy table defined in RFc3484. Once the source address  
> selection is done, the

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 12 Apr 2007 16:26:37 +0900

Hi,

> source address selection and output interface selection is done at the same

As far as I know, the incoming interface and the outgoing interface
isn't necessarily the same on almost every major OSes.
This issue is related to Strong ES model and Weak ES Model defined
in RFC 1122. I guess almost every OSes implements Weak ES Model.

> and sends out from the same interface as the packet comes.

As for the destination address, it's perfectly true.

The problem statement draft describes only those problems that
happen at originator hosts.

> outing going interface is selection accordingly.

When choosing the source address, as you see in RFC 3484, 
the addresses attached to the outgoing interface are preferred.
The outgoing interface is determined by looking up the routing
table together with the destination address.

In some cases, the outgoing interface is changed by a packet
filter or something like that, though.

Kindest regards.

-- 
Arifumi Matsumoto
    IP Technology Expert Team
    Secure Communication Project
    NTT Information Sharing Platform Laboratories
    E-mail: [email-masked]