Subject: RE: draft-ietf-default-addr-select-04.txt (fwd)

From: "Richard Draves" <[email-masked]>
Date: Wed, 8 Aug 2001 22:26:52 -0700

[As some of you know, I've been away from email for the past two months.
I am still not on any email lists, ipng included.]

See comments below...

> -----Original Message-----
> From: Mauro Tortonesi [mailto:[email-masked]] 
> Sent: Sunday, July 29, 2001 11:54 AM
> To: Richard Draves
> Subject: draft-ietf-default-addr-select-04.txt (fwd)
> 
> 
> 
> you've probably missed this mail i've posted to the ipng ml ;-)
> 
> -- 
> Aequam memento rebus in arduis servare mentem...
> 
> Mauro Tortonesi			[email-masked]
> Ferrara Linux User Group	http://www.ferrara.linux.it
> Project6 - IPv6 for Linux	http://project6.ferrara.linux.it
> 
> ---------- Forwarded message ----------
> Date: Fri, 20 Jul 2001 19:07:29 +0200 (CEST)
> From: Mauro Tortonesi <[email-masked]>
> To: [email-masked]
> Subject: draft-ietf-default-addr-select-04.txt
> 
> 
> last monday i have revised 
> draft-ietf-default-addr-select-04.txt, and i have some 
> questions and minor editorial comments:
> 
> 
> Page 1:
> 
> Abstract
> 
> [...]
> 
>    All IPv6 nodes, including both hosts and routers, must implement
>    default address selection as defined in this specification.
> 
> why "must" and not "MUST"?

I have the vague impression that it's best to avoid overuse of
capitalized MUST/SHOULD/etc, but I am happy to defer here to those with
more RFC experience.

> Page 5:
> 
> 
> 2.3. IPv6 Addresses with Embedded IPv4 Addresses
> 
>    IPv4-compatible addresses [2] and 6to4 addresses [12] contain an
>    embedded IPv4 address. For the purposes of this document, these
>    addresses should be treated as having global scope.
> 
>    IPv4-compatible addresses should be treated as having "preferred"
>    configuration status.
> 
> what about 6to4 addresses? shouldn't they be treated as 
> having "preferred" configuration status too? what about other 
> embedded address types?

6to4 addresses will typically be acquired via usual address
configuration means (like receiving a prefix in a Router Advertisement)
so their configuration status will depend on their lifetime, just like
other global addresses.

> 2.4. Loopback Address and Other Format Prefixes
> 
>    The loopback address should be treated as having link-local
>    scope [9, section 4] and "preferred" configuration status.
> 
> this has already been (partly) stated in section 2.1.

I don't see how section 2.1 says anything about the loopback address.

> 2.5. Policy Table
> 
> [...]
> 
>    The precedence value Precedence(A) is used for sorting destination
>    addresses. If Precedence(A) > Precedence(B), we say that address A
>    has higher precedence than address B, meaning that our algorithm
>    will prefer to sort destination address A before 
> destination address
>    B.
> 
> i would change this into:
> 
>    The precedence value Precedence(A) is used for sorting destination
>    addresses. If Precedence(A) > Precedence(B), we say that address A
>    has higher precedence than address B, meaning that our algorithm
>    will prefer to sort destination (or source) address A before
>    destination (or source) address B.

I disagree. Because the Precedence value is used only when sorting
addresses for use as a destination (section 5) it would be highly
misleading to insert a reference to source addresses.

> Page 10:
> 
> 6. Interactions with Routing
> 
> [...] One router is advertising a global prefix A and
>    the other route is advertising global prefix B.
>              ^^^^^
> 
> i think you wanted to say router here.

Yes, thanks.

> IMHO, draft-ietf-default-addr-select-04.txt is a very well 
> done work. i wonder how many implementations already support 
> source and destination address selection. does any of you 
> have some information about this?

The MS implementation supports the draft.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 13 Aug 2001 05:27:01 +0900

>>>>> On Wed, 8 Aug 2001 22:26:52 -0700, 
>>>>> "Richard Draves" <[email-masked]> said:

> The MS implementation supports the draft.

The recent versions of KAME snapshot releases for *BSD have a partial
support of the destination ordering.  "Partial" means that the
implementation skips some of the rules specified in the draft.  For
example, it does not support the flexible policy table.

You can freely refer to the implementation at KAME's
libinet6/getaddrinfo.c.

We're also planning to implement the source address selection part in
the KAME stack, probably in the very near future.

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