>>>>> On Thu, 24 May 2001 14:26:24 -0700,
>>>>> Bob Hinden <[EMAIL PROTECTED]> said:
> This is a IPng working group last call for comments on advancing the
> following document as a Proposed Standard:
> Title : Default Address Selection for IPv6
> Author(s) : R. Draves
> Filename : draft-ietf-ipngwg-default-addr-select-04.txt
> Pages : 20
> Date : 14-May-01
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the author. This last call period will end two
> week from today on June 7, 2001.
I have several comments on the latest draft. Most of them are
editorial or minor details, but I believe some of them are
substantive, or at least controversial (so I post them to the list).
(BTW, I basically think the draft gives a good guidance to
implementors. I support the basic idea of the draft.)
2.1. Scope Comparisons
The IPv6
addressing architecture defines scope field values for node-local
(0x1), link-local (0x2), site-local (0x5), organization-local (0x8),
and global (0xE) scopes [9].
Here are some inconsistency comparing to the latest versions of the
scoping/address architecture drafts:
- node-local scope was obsoleted by "interface-local"
- two new scope value "(reserved for) subnet-local = 0x4" and
"admin-local scope = 0x5" were defined.
2.5. Policy Table
Policy table entries for scoped address prefixes MAY be qualified
with an optional scope-id. If so, a prefix table entry only matches
against an address during a lookup if the scope-id also matches the
address's scope-id.
I believe "zone-id" is a better wording than "scope-id", according to
the scoping architecture draft. This comment is applied to all other
occurrences of "scope-id" in this draft, too.
3. Candidate Source Addresses
For multicast and link-local destination addresses, the set of
candidate source addresses MUST only include addresses assigned to
interfaces belonging to the same link as the outgoing interface.
For multicast addresses, I think this is too restrictive. I know the
rationale is the reverse path forwarding in the multicast routing
architecture, but I believe users should be allowed to use other
candidates, with respecting to the multicast routing architecture
(e.g. users should be able to use a global address assigned on the
loopback interface as the source address for a multicast packet being
sent to a physical (i.e. not the loopback) interface).
Thus, I think SHOULD or RECOMMENDED is suitable for the multicast
case.
4. Source Address Selection
Rule 7: Prefer public addresses.
If SA is a public address and SB is a temporary address, then prefer
SA. Similarly, if SB is a public address and SA is a temporary
address, then prefer SB.
An implementation may support a per-connection configuration
mechanism (for example, a socket option) to reverse the sense of
this preference and prefer temporary addresses over public
addresses.
I'm not sure if this is a good policy. When a temporary address is
assigned, the administrator of the host should want privacy about
addresses that appear on the wire, so the administrator should want to
use the temporary address by default. If the default is not to use
the temporary one, then the public address would accidentally appear
on the wire, revealing the identity of the sending node to some
tracking guy. I don't think this is the desired story that the
administrator wants. If the administrator does not care about the
privacy so much, the administrator should just turn off generating
temporary addresses. Once the mechanism is turned on, the use of
temporary addresses should be respected, IMHO.
By the way, I recall that there was a discussion about the preference
between public addresses vs temporary addresses, but I don't remember
the result of the discussion. If I'm raising an issue that has
already been fully discussed and got consensus, I'd apologize in
advance. (But I can't believe the consensus was to prefer public
ones...)
5. Destination Address Selection
Rule 1: Avoid unusable destinations.
If there is no route to DB or if Source(DB) is undefined, then sort
DA before DB. Similarly, if there is no route to DA or if Source(DA)
is undefined, then sort DB before DA.
I think "no route to DB" here is a bit confusing for IPv6 hosts, based
on the neighbor discovery specification. Section 5.2 of RFC 2461
says:
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packet's destination is on- or
off-link. If the destination is on-link, the next-hop address is the
same as the packet's destination address. Otherwise, the sender
selects a router from the Default Router List (following the rules
described in Section 6.3.6). If the Default Router List is empty, <----
the sender assumes that the destination is on-link. <----
According to the text, every destination has a default route to it or
is regarded as on-link. In other words, there should always be a
"route" to every destination. I think we need some clarification
about the notion of "no route" here, probably using the
(non-)existence of a default router...?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
