On Apr 3, 2007, at 2:26 AM, Ruri Hiromi wrote:
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?
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.
(2) how? any ideas? references?
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.
====
(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
hiromi@inetcore.com