Hello,
Thank you for comments on the draft. I've been on a short vacation and
now the students are coming back, so I have a handful of excuses for not
having responded faster. O:-)
Brian E Carpenter wrote:
2.2. Autoconfiguration for Global Scope
This usually means that the next hop of that default route will only
be useable with the source address learned from that default router.
Can you be more explicit that any global scope routing table MAY
contain a default route and that the default route could be different
for each source address? (I do mean MAY; there might be source addresses
with no default route.)
I've been rewriting the draft with this idea in mind:
If an address has a default route, it is global scope.
If an address does not have a defaut route, it's link local, site local
or some other limited scope.
This means that even 192.168.1.33 can be global scope, when it's behind
a NAT box that is connected to the Internet.
2.3. Site Local Scope
Since we abolished this for IPv6 and it is undefined for IPv4,
could you try a more neutral phrase such as
I was thinking of RFC1918 and ULA when I was writing this.
2.3. Limited Scope
Is this the term used by the ULA drafts?
(Maybe I should add them to my reading list too ...)
I'll try to start using this term.
(For some thoughts about limited scope,
see draft-carpenter-behave-referral-object.)
I'm trying to keep my algorithm itself completely scope agnostic,
although your idea of ScopeIDs could be very useful in identifying when
two or more interfaces belong to the same routing domain and their
tables could be combined in forwarding or routing protocol cases.
Although right now I'm reconsidering removing the forwarding and routing
protocol sections from the draft, since they only seem to cause confusion.
3.1. Route and Table Preferences
...
In order to perform source address selection, only one destination
address SHOULD be presented to the algorithm, which will then look
for the address in all tables and sort the source addresses where it
was found according to the precedences.
In order to perform destination address selection, only one source
address SHOULD be presented to the algorithm along with the set of
destination addresses. The algorithm will then look for all the
given destination addresses in the table associated with the source
address and sort the results according to the precedences.
I see this as a bit of a problem. The underlying issue for
host-based multipath approaches (including shim6) is to pick
the best address pair, not to pick the best source given a
destination or vice versa. We should allow for such an algorithm
as well.
Heh, it feels nice to find a kindred spirit. (My original impetus for
starting to work on this draft was host-based multi-homing :-)
The algorithm presented in the draft works on address pairs ONLY.
The two paragraphs you quoted are there to explain how the algorithm can
be used to perform "one sided address selection", for backwards
compatibility with RFC3484 which doesn't support any other notions.
I guess I should move those paragraphs into some other part of the
document and maybe give them a more descriptive title.
--
Aleksi Suhonen
Department of Communications Engineering
Tampere University of Technology
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
