> I have some concerns about the details, primarily because my years of
> working on a "strong host model" network layer have led me to really
> question that model. It's probably too late, for the
> protocol stack I work
> on, but I'd like to make sure it's easy for other
> implementers to use a weak
> host model. Also, I want to make sure applications are
> empowered to select
> their own addresses with minimal second-guessing at the network layer.
You get into these issues in more detail below, but the quick summary is
that applications can select their own addresses (by binding to a specific
source address) and the draft recommends but does not require the strong
host model, per WG consensus.
> > All IPv6 nodes, including both hosts and routers, must implement
> > default address selection as defined in this specification.
>
> It seems funny to have a "must" (different from a "MUST"?)
> in the abstract,
> and since half the draft talks about destination address selection
> (typically not an issue for routers, which may not even include a BIND
> resolver or host table), I don't see why routers are required
> to implement
> it.
When routers are forwarding packets, the draft doesn't apply since they are
not performing source or destination address selection. But when routers do
perform source or destination address selection, then I believe the draft
should apply. So I think it is appropriate for the scope of the draft to be
all IPv6 nodes.
> > The IPv6
> > addressing architecture defines scope field values for node-local
> > (0x1), link-local (0x2), site-local (0x5), ...
> > ...
> > IPv4 loopback addresses [11, section 4.2.2.11], which
> > have the prefix 127/8, are assigned link-local scope.
>
> Why not node-local, since you went to the trouble of
> mentioning it earlier?
draft-ietf-ipngwg-scoping-arch-01.txt also says that the loopback address
has link-local scope. One reason for not using node-local is that this would
introduce a big exception, because all other unicast addresses are
link-local, site-local, or global.
> Consider this source address selection problem:
>
> Destination: fe80::2
> Sources: fe80::1 (deprecated) vs ::1
> Result: ::1 (avoid deprecated address)
>
> Is it legal to have a deprecated link-local address? If so, this
> configuration is valid, and the result is non-intuitive.
Yes, it is legal to have a deprecated link-local address. Although the
situation will never arise as a result of address autoconfiguration, it can
happen with manual configuration.
I assume in your scenario, you mean that fe80::1 is assigned to eg an
ethernet interface and ::1 is assigned to the loopback interface. And
fe80::2 is a neighbor on the ethernet interface. In this case, the candidate
set will include fe80::1 but not ::1, because the candidate set can only
include link-local addresses assigned to interfaces on the same link as the
originating interface. So ::1 will be excluded from the candidate set.
So the result is fe80::1, which I think is the answer you want. Actually,
the ethernet interface would usually have a non-deprecated link-local
address which would get chosen instead.
> become redundant. Alternatively, perhaps the cleanest
> solution would be to
> add something like this to sec 3:
>
> For non-loopback destination addresses, the set of
> candidate source addresses MUST NOT include any
> loopback addresses.
I think the above analysis shows that additional text is not needed.
> > It is RECOMMENDED that the candidate source addresses be the set of
> > unicast addresses assigned to the interface that will be used to
> > send to the destination. (The "outgoing" interface.)
>
> Whoa! That's pretty restrictive. Keep this in mind, as many
> of my other
> concerns stem from the possibility that some implementors may
> follow this
> RECOMMENDATION.
It might be helpful to review the RFC 2119 definition:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
In discussions last year, it seemed the WG consensus was to prefer the
strong host model but allow use of the weak host model - I'm trying to
reflect that consensus with this wording.
> > On routers, the
> > candidate set MAY include unicast addresses assigned to any
> > interface that could forward the destination address to
> the outgoing
> > interface.
>
> This wording presumes a lot about the implementation, and
> seems to imply
> that only routers MAY deviate from your RECOMMENDATION.
It does not imply that only routers may deviate from the recommendation. It
does outline one specific deviation that routers may want to implement.
(This stems from the discussions last year about the strong vs weak question
- some of the examples from weak proponents involved routers.)
> > For multicast ... destination addresses, the set of
> > candidate source addresses MUST only include addresses assigned to
> > interfaces belonging to the same link as the outgoing interface.
>
> Hmm. What if I'm a multicast router? I'm specifically
> concerned about the
> case of a node which is sending a multicast stream, where the
> node's owners
> have gone to great lengths to achieve reliability. They may have some
> application-specific reason why all the packets in this
> multicast stream
> need to have the same source address (to be granted preferred routing
> treatment, perhaps, or to traverse firewalls). That means
> the application
> will bind to a particular global address -- say, one associated with
> interface A. If the ISP for interface A fails, we now need to send
> multicast packets with A's source address out interface B,
> switching to our
> backup ISP, with whom we have presumably made advance
> arrangements to carry
> the traffic.
Steve Deering (I think it was) said that some multicast routing protocols
break if packets are sent with a source address that is assigned to a
different interface. (I don't know enough about multicast routing to vouch
for this myself.) Hence this requirement for multicast destinations.
> router. Here again,
> we need the packets to go out with a consistent global source address,
> regardless of the routing decisions.
Implementations that want to use a weak host model can do so, if the
consequences have been understood and weighed.
One of the consequences is that Redirects will not work properly if a host
uses the weak model.
> > If an application or upper-layer specifies a source address that is
> > not in the candidate set for the destination, then the
> network layer
> > MUST treat this is an error.
>
> Again, this is what gives me heartburn, particularly in light of that
> earlier RECOMMENDATION that the candidate set include only
> those source
> addresses associated with the outgoing interface. If the
> application has
> gone to the trouble of binding to a particular local address,
> then I think
> the network layer should go ahead and use that source
> address, even if the
> routing table happens to dictate that the packet gets
> transmitted out a
> different interface. This is particularly true if the
> routing table changes
> during a particular information flow (UDP application dialog or TCP
> connection). At that point, we can't change the source
> address, even though
> we are suddenly sending the packets out a different interface
> which may well
> have available addresses of its own.
Again, this is the same strong vs weak argument.
> In general, perhaps the set of source addresses which can be specified
> explicitly by an application should be larger than the set of
> addresses
> which might be automatically selected by the network layer.
> Don't try so
> hard to protect the network from misbehaving applications.
I disagree with this. An application must not send a packet with an anycast
or multicast or unspecified source address. An application must not send a
packet out one interface with a link-local source address that is assigned
to an interface on another link.
And if my network layer implements the strong model, then an application
must not send a packet out one interface with a global source address that
is assigned to a different interface. But if your implementation uses the
weak model, then you will allow this. The draft allows it.
> > Rule 2: Prefer appropriate scope.
> > If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB
> > and otherwise choose SA.
>
>
> I found this rule quite hard to understand.
Would it help if I added some explanation, say
Rule 2: Prefer appropriate scope.
This rule selects the source address that is closest in scope to the
destination.
???
> > Rule 5: Prefer outgoing interface.
> > If SA is assigned to the interface that will be used to send to D
> > and SB is assigned to a different interface, then prefer SA.
>
> Yes! I agree with this rule. This is a good way to prefer addresses
> associated with the outgoing interface. Of course, it only
> comes into play
> when an implementation deviates from your RECOMMENDATION that
> only addresses
> assigned to the outgoing interface be considered. It's
> rather telling that
> when you had to rank this rule, you put it down at number 5, while the
> RECOMMENDATION would effectively make it number 0.
Actually I'm not sure where to rank rule 5. Since my implementation follows
the recommendation, rule 5 doesn't get used. I put it after the mobility
rule because some implementations might assign home addresses to a pseudo
interface or something. Since you've thought a lot about weak host model
implementations, I'd appreciate your feedback on the ranking of rule 5 in a
weak host model implementation.
> > ...no more than one second out
> > of date. For example, an implementation might make a system call to
> > check if any routing table entries or source address assignments
> > that might affect these algorithms have changed.
>
> Well, that would probably take several system calls, so doing
> it every 1
> second sounds too frequent, to me. I'd think 5 or 10 seconds would be
> appropriate.
Several system calls once a second is negligible. Especially for a process
that is doing network IO.
In practice, I expect most implementations will just have getaddrinfo() call
down to the network layer to do the address sorting. But the draft allows
for other designs.
> Bearing in mind that the output from this selection process
> should be a list
> of address pairs to try, I can't help observing that the results are
> sometimes suboptimal. As written, this design will lead well-behaved
> applications to try a list of *destination* addresses, in
> some reasonable
> order. However, for each destination address, we'll try only a single
> source address.
First, the connect() API might try multiple source addresses before failing,
or try multiple source addresses in parallel. (If the application has not
bound a specific source address.) I don't know if anyone does this.
As you noted, a connect-to-name API (or giving connect a list of addresses)
would get the best results. The idea has certainly been discussed often
enough. I believe MacOS in fact has such an API.
The draft could be extended to give more guidance to such implementations,
but at this point it hasn't seemed to be an important goal.
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]
--------------------------------------------------------------------
