Subject: I-D Action:draft-ietf-6man-rfc3484-revise-01.txt

From: [email-masked]
Date: Thu, 14 Oct 2010 23:30:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Update to RFC 3484 Default Address Selection for IPv6
	Author(s)       : A. Matsumoto, et al.
	Filename        : draft-ietf-6man-rfc3484-revise-01.txt
	Pages           : 10
	Date            : 2010-10-14

RFC 3484 describes algorithms for source address selection and for
destination address selection.  The algorithms specify default
behavior for all Internet Protocol version 6 (IPv6) implementations.
This document specifies a set of updates that modify the algorithms
and fix the known defects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 15 Oct 2010 15:40:59 +0900

All,

the 01 version was largely restructured, so that it serves as an update statement to the RFC 3484. The 00 version was rather a list of considerations related to RFC 3484 update.

We had long discussion before about several issues, such as longest matching algorithm. In my understanding, we could not reach a consensus at that time. Those unconcluded issues were moved to the appendix part in this version.

Best regards,

On 2010/10/15, at 15:30, [email-masked] wrote:

> <Mail Attachment>--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [email-masked]
  TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2010 15:31:49 +1300

Hi,

I think this draft is looking good. A couple of points:

> 2.1.3.  Deprecated addresses in the policy table
> 
>    IPv4-compatible IPv6 address is deprecated.  [RFC4291] IPv6 site-
>    local unicast address is deprecated.  [RFC3879] Moreover, 6bone
>    testing address was [RFC3701] The issue is how we treat these
>    outdated addresses.

The sentence about 6bone is incomplete. I think the answer for 6bone
is that 3ffe::/16 is just another reserved unicast prefix now, but it
may be allocated one day. So why list it at all? It's just part of
2000::/3 now.

The only exception might be 3ffe:831f::/32. That was used as an
experimental Teredo prefix, so it might be wise to list it with low
precedence. But even that could cause a problem many years from now,
when 3ffe::/16 is assigned as unicast space.

For the other deprecated addresses, listing them with low precedence
seems correct.

> 5.1.  Normative References

It seems to me that very few of the references are actually normative.
Most of them should be moved to "Informative".

Regards
   Brian Carpenter

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 27 Oct 2010 15:18:39 +0900

Hi,

> For the other deprecated addresses, listing them with low precedence

Thank you for your comment.

Considering the nature of the default address selection policy,
it is hard to be updated, and it takes time to do that even revising
the RFC.

So, I agree that the temporary situation should not be reflected
on the default address selection policy.

In that sense, 3ffe::/16 and 3ffe:831f::/32 should not be specially
treated.

> Most of them should be moved to "Informative".

Could you please tell me which ones do you think should be kept ?