> > I'd like to hear more feedback from the WG on this point.
> > Should the suggestion of configurability be "SHOULD" or "MAY"
> > or "may" or ???
> >
> > I certainly agree it should be optional, but I'd like to
> > encourage implementations to be configurable with mechanisms
> > like policy table or equivalent functionality, because those
> > mechanisms can be used in multi-homing situations (both sites
> > connected to multiple ISPs and hosts with multiple
> > interfaces) to control choices of source & destination address.
> >
>
> I agree that this feature could be very useful in multi-homing
> situations, but would it be used much? If each vendor implements
> the management hooks their own way, network administrators would
> quickly find the hassle of defining this information on every
> node in a site out-weighs the benefits. I think it would be
> reasonable for vendors to postpone implementation of this
> mechanism until additional configuration tools are well defined.
Hmm. This argument could apply reductio ad absurdum to every aspect of an
implementation's configurability. For example, router's are configurable and
there's no IETF standard for configuring them (maybe I'm just ignorant) but
network administrators still find it useful to configure routers.
In particular, RFC 2461 section 6.2.1 defines conceptual variables that MUST
be configurable, but it does not specify a standard protocol or mechanism
for configuring them.
How is this any different from my draft specifying a conceptual policy table
that SHOULD be configurable, but not having a standard protocol or mechanism
for configuring it?
> I think you may have missed the point of my question. The
> default policy table contains the following lines:
>
> ::ffff:169.254.0.0/112 30 7 7
> ::ffff:10.0.0.0/104 20 8 8
> ::ffff:172.16.0.0/108 20 9 9
> ::ffff:192.168.0.0/112 20 10 10
> ::ffff:0:0/96 10 11 11
>
> Instead of just:
>
> ::ffff:0:0/96 10 11 11
>
> I was questioning if subdividing the V4-mapped addresses
> in the table is a good thing.
I've concluded that having policy entries for different scopes is not a good
thing, it's getting in the way of the rules that deal with scoping. And see
my reply to Brian - looks like we can't have v4-mapped addresses in the
policy table at all.
> I see your point. I'm not terribly concerned what happens
> when both addresses are of insufficient scope. The network
> configuration is clearly broken if it comes down to this
> choice anyhow. How about something like:
>
> Rule 3a: Avoid insufficient scope for destination.
> (i.e., avoid Scope Source < Scope Dest) If both
> addresses have insufficient scope, prefer the one
> with higher scope.
>
> Rule 4: Avoid deprecated addresses.
>
> Rule 3b: Prefer lower scope.
>
> > If we're going to simplify this, I actually favor just giving
> > appropriate scope absolute priority over
> > preferred/deprecated. The preferred/deprecated parts of the
> > current rule 3 are a response to comments from Erik Nordmark,
> > if I remember correctly.
>
> I wouldn't do that. We should support graceful renumbering
> of a network from site-local addresses to global addresses.
> In this situation, one would intentionally configure a router
> to advertise a deprecated site-local prefix.
You are describing a scenario where a site transitions from using both
site-local & global addresses to only using global addresses?
So a node A has global address Ag and site-local address As. And node B,
that is trying to connect to A, has addresses Bg and Bs.
Now the network administrator deprecates site-local addresses across the
site.
I think this would also result in the site-local addresses being removed
from DNS. You don't want to have deprecated addresses in the DNS.
So when node B looks up node A, it only finds Ag. And source address
selection on node B will pick source address Bg.
Maybe the point you are making applies to destination address selection.
Would you want to see a destination address selection rule like this: when
comparing destination addresses DA and DB, if Source(DA) is not deprecated
and Source(DB) is deprecated, then sort DA before DB?
> I don't think we should use MUST unless violating a rule breaks
> interoperability. I agree with you that inconsistency between
> implementations is not good. Still, we need to allow
> implementations the freedom to deal with issues not foreseen
> by us today. That's why I prefer words like RECOMMEND and
> SHOULD on the order of the rules.
OK, I think I buy this. Off hand, this means that candidate set definition
and the source address selection rule(s) relating to scope would be MUST,
and everything else would be SHOULD.
For example, the source address selection rule saying that deprecated
addresses should be avoided, would be SHOULD instead of MUST because it does
not affect interoperability. Is everyone OK with this?
> > Many of the individual rules are collected from other places.
> > For example, avoiding deprecated addresses comes from RFC
> > 2462. Preferring anonymous addresses comes from the privacy
> > draft. The real contribution of this section isn't the rules
> > themselves, it's supplying consistency by giving them an order.
>
> Agreed. Is there any other spec that specifies "avoid
> insufficient scope"?
Not in so many words, but draft-ietf-ipngwg-scoped-routing-03.txt can be
construed that way.
> I was thinking cost, QoS, performance, or even political/
> contractual considerations may become important factors
> in address selection in the future. I can't say how, but
> I can see why an implementer may need have such
> considerations override most other rules.
If Congress passes a law, I think that will supercede an IETF standard. :-)
More seriously, see the MUST/SHOULD discussion above.
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
