Hi,
Brian, thank you for giving us comments on this.
Let me explain the current status of this whole issue of address selection here
in this e-mail.
At the last 6man session, this item's approval was delayed due to a yet-to-come
alternative mechainsm. But, that proposal is still not yet available. I do not
want this item delayed further.
So, as the chairs suggested, I think the next step should be starting
discussion about the design team's output. That output are basically,
- promotion of DHCP based policy table update
draft-fujisaki-6man-addr-select-opt
- promotion of RFC 3484 revision
draft-ietf-6man-rfc3484-revise-01
I just posted a revision, as I wrote in the previous e-mail.
Some comments below.
On 2010/10/15, at 12:10, Brian E Carpenter wrote:
> Hi,
>
> I finally got to this draft.
>
> It seems fine to me in general (of course, it needs review by the DHC WG).
Yes. As this is basically related to IPv6 and not DHCP, we changed the
filename to 6man. Of course it needs review from DHCP point of view.
> However, I got hung up on the zone-index field. As you say,
> "However, in general case, it is hard to use this value."
>
> I think that's very polite! It seems to me that the definition in RFC3493
> is basically useless at site-wide level, and in this case we need to
> consider site-wide or even Internet-wide values being delivered to hosts.
> As 3493 says, "The mapping of sin6_scope_id to an interface or
> set of interfaces is left to implementation and future specifications..."
> and that is still true today.
>
> I think we have no idea how to use this zone-index field. I think it
> is possibly useful to mention it, but it should (IMHO) be marked as
> reserved and not to be used. Also, I am not sure that it is OK to
> make it 32 bits. There's at least one proposal for generic scope IDs
> that would use 128 bits (OK, that's an expired I-D of my own, but it
> shows that we really don't know what to do about this yet).
Good suggestion.
We had several comments on the zone-index before. And the only reason we
keep it as it is is that we cannot prove the non-existence of use case.
Regarding the size of it, one of the restriction is the basic socket API
in RFC3493.
struct sockaddr_in6 {
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 flow information */
struct in6_addr sin6_addr; /* IPv6 address */
uint32_t sin6_scope_id; /* set of interfaces for a scope */
};
If scope id equals to zone index, it means the zone index is 32bit length.
Of course, this does not mean other implementation uses 128bit scope id.
Best regards,
--
Arifumi Matsumoto
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: arif...@nttv6.net
TEL +81-422-59-3334 FAX +81-422-59-6364
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
