Subject: W.G. Last Call on "Default Address Selection for IPv6"

From: Bob Hinden <[email-masked]>
Date: Thu, 24 May 2001 14:26:24 -0700

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.

Bob Hinden / Steve Deering

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 25 May 2001 07:50:54 +0900

>week from today on June 7, 2001.

	were there concrete agreement made about standard-track/informational?
	i find the following on IETF50 minutes, nothing else (correct me
	if i'm wrong).  were there any poll on mailing list made?
	http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt

itojun

---
Jim Bound thinks this shouldn't be a standard, should be informational.
Thinks is policy.  This should be suggested recommendation, not default.
Draves: Thinks this document does have implementation requirements.
"Must" requirement have implementation consequences.  Bound: Doesn't
agree with some of the choices (e.g., selection of site scope as source
to send to global destination).
(snip)
Nordmark:  Thinks this should be standards track.  Splitting between must
and should.

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 May 2001 11:02:13 -0400 (EDT)

Hi,

I may still object to it being a standards document.  I read roughly the
04 draft.  My main issue is that I do not believe one should EVER use a
site-local address when sending to a GLOBAL address unless one has a
global address available.  This does not appear to be a requirement of the
algorithm, but I will check again on my plane ride to Seattle.  If it is I
can't see any argument changing my mind for the default behavior.

As far as it being standards tracked I will forgo that issue and the
reason is that precedence has been changed via ngtrans with some of the
specs being standards tracked for transition and rich's work is better
than a few of those in some instances and if they are standards track then
so should this be.  I do believe though we in the IETF are on a slippery
slope here and need to be careful for any pandora's box we have opened for
lets say 2006 when we are working on technology we may not for see now as
standard vs informational.  I should probably write a position paper on
this for the IESG and IAB as an objective treatise of IETF epistemology.

As far as policy I hav changed my mind on this a bit because I think we
could cause a mamor problem with IPv6 if we don't at least give some
default guidance to the vendors and market regarding use of our multi
scoped addressing architecture.  My normal laizze-faire view of our work
here and my support or not support needs to be tempered in this case.

But then we get down to what is right and wrong.

Using same scope should be done as DEFAULT.  Anything else is very very
bad.  My belief is that what Rich did.  But want to check one more time on
the plane.

My other concerns are how the wording is in the selection process and if
the spec tells me how I must implement this in libc, APIs, and most
importantly how I would do the conditionals and data structures to support
the draft.  If it is left open and not forced by any IETF SHOULD or MUST I
am fine with it for my reasons above.  I will check this on the plane
too.

As far as the issues not being resolved and the chairs sending a last
call.  Well I will assume they belived the last call will flush the final
discussions out on the list.  But I do think all the attached issues
should be resolved.

thanks

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 May 2001 11:16:02 -0400 (EDT)

sorry.  Do not use site-local when sending to global if one has a global
source address should be the default.

/jim

---

From: Robert Elz <[email-masked]>
Date: Fri, 25 May 2001 22:46:46 +0700

Standards track is clearly right for this doc.   It isn't just
policy - in fact, it isn't really policy at all.  It expressly
says that local policy can override the rules, but otherwise
specifies how nodes should behave, and I think specifies stuff
that is needed for correct interoperbility.

I would delete the (I think just one, but I might have missed something)
reference to getaddrinfo() though - what is done in that func, and
what is done elsewhere, really is a local implementation issue, and
shouldn't be in this doc.   Don't specify (to a large degree, don't
even hint at) how or where it should be done, just that it should be.

For Jim ... I think you'll find if you read the doc, that it meets your
requirements on site-local and global addresses - it will pick addresses
of the same scope if such addresses exist.   That is, unless that has
been overridden by the application (or something) of course - that is,
the draft doesn't prohibit using a site local address when sending to
a global, it just won't generate that by itself unless no global is
available.   That's how it should be I think.

I happen to believe there are good reasons for sending to a global
address from a site local - but when that's do be done it ought be
done by the application/library/whatever deliberately, the way the
draft has it is fine - absent other info, send to a global from a global.

kre

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 May 2001 13:12:23 -0400 (EDT)

OK folks.  I dropped what I am doing and checked my issues they do seem to
be solved.  I agree with Robert also on the getaddrinfo comment too.

good job Rich............

thanks

/jim

---

From: Bob Hinden <[email-masked]>
Date: Fri, 25 May 2001 14:11:52 -0700

Itojun,

>http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt

Steve Deering and I concluded that it is important for "Default Address 
Selection for IPv6" to be standards track to insure that all 
implementations had the same default behavior.  Otherwise there might be an 
interoperability problems.  I think the discussion at the last IETF meeting 
supported this approach, but the minutes, as you pointed out, could have 
been clearer.

Thanks,
Bob

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 May 2001 09:53:42 -0700

>week from today on June 7, 2001.

The NGtrans wg is looking at the ISATAP proposal
draft-ietf-ngtrans-isatap-01.txt
that may or may not have impact on default address selection.

We will discuss this issue at the upcoming Interim Meeting in Seattle on 
Friday.

         - Alain.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 May 2001 17:34:47 +0900

>>>>> On Thu, 24 May 2001 14:26:24 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> 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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 May 2001 15:58:17 +0700

Date:        Thu, 31 May 2001 17:34:47 +0900
    From:        JINMEI Tatuya <[email-masked]>
    Message-ID:  <[email-masked]>

  | Here are some inconsistency comparing to the latest versions of the
  | scoping/address architecture drafts:

Here I think it is better to use the values from the currently published
RFCs - the actual numbers aren't important to anything in this draft,
and using data from a doc that isn't yet an RFC will only serve to hold
up this one until that is eventually published.

Just use what exists now, and then allow the later doc to update the
numbers when it appears.

  | 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:

That section can really only apply after interface selection (routing)
has been done - that is, it is assuming that a link has been selected
to send the packet upon, at that stage one can compare prefixes, select
the next hop, or send it as on-link traffic.   But before that is done,
something has to select the interface.   Even for hosts with only one
piece of electrical gizmo called an interface (or NIC) is likely to have
at least an internal software "loopback" interface, and perhaps some
tunnels as well.  Something has to have selected one of those, and during
that selection there's always the possibility that "none of the above"
is the answer obtained.   I suspect that's what the "no route to DB"
is referring to (that's certainly the way I understood it).  For many
hosts that answer will never occur, and that section of the address
selection draft won't be helpful - for others, it can occur.

kre

---

From: Pekka Savola <[email-masked]>
Date: Thu, 31 May 2001 12:42:36 +0300 (EEST)

On Thu, 31 May 2001, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
[snip]
> (non-)existence of a default router...?

Also, the default address selection draft wording assumes that off-link
destinations are only reachable through default router(s).

Address selection should be worded to apply cleanly to a situation where
there is no default route, but basically nearly equivalent static routes:
it could be quite common that there is no default router at all, only e.g.
2000::/3 for example.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Jun 2001 02:42:27 +0900

>>>>> On Thu, 31 May 2001 15:58:17 +0700, 
>>>>> Robert Elz <[email-masked]> said:

> up this one until that is eventually published.

Okay, I don't mind the policy.  But then, the addr-select draft should
refer to RFC 2373, instead of the scoping architecture draft:

   Multicast destination addresses have a 4-bit scope field that 
   controls the propagation of the multicast packet. 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]. 
                           ^^^ this should be RFC 2373.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Jun 2001 02:33:28 +0200

I strongly object against the standard track status for this document
because this will close the door:
 - research won't be done in order to find alternate/better solution
 - implementors will have to implement exactly the mechasnims described
   in the document or they won't be conformant.
The first point is a known drawback for standards. My concern is more
the second point, I understand we have to restraint freedom for getting
more interoperability but in this case we are going too far!
 Some choices are still arguable, in particular in defaults, and these
will become standards so even we believe they are not good we will be
stuck with them.
 These concerns have already slowed down the document and can become
critical when it will go further in the standard track. Common sense
rules ("MUSTs") should be in a different document than some detailed
mechanisms ("SHOULD/MAYs").

Regards

[email-masked]