Can someone explain the rational for why RFC 4007 mandates the scope
zone index before the prefix in the textual representation?
It appears to be the reverse of what I would expect. A prefix is
assocaited with the IP address itself (in6_addr), while the scope zone
index is associated with the socket address (sockaddr_in6), therefore it
would appear to make more sense if the prefix were bound more closely to
the IP address than the scope zone index.
To illustrate:
Suppose we have a function in6_addr_pton which converts a textual
representation of an IP address to an in6_addr. I would expect such a
function to accept prefix notation, but not scope zone index notation
(since scope_id is stored in a sockaddr_in6 and not in an in6_addr).
Likewise, assuming a function, sockaddr_in6_pton, which converts a
textual representation of a transport address (i.e. IP + port), I would
expect it to accept both prefix (passed with IP address to
in6_addr_pton) and scope zone index (as well as port) notation.
/* Convert text in the form "ip6 ['/' prefix]" to in6_addr */
int in6_addr_pton(const char* str, in6_addr* addr) {}
/* Convert text in the form "'[' ip6 ['/' prefix] ['%' scope] ']' ':'
port" to sockaddr_in6 */
int sockaddr_in6_pton(const char* str, socketaddr_in6* sa) {
call in6_addr_pton() with substring "ip6 ['/' prefix]" to
extract IP address to sa.sin6_addr
extract scope ID (if present) to sa.sin6_scope_id
extract port to sa.sin6_port
}
Section 11.7 says its important to put the scope zone index first for
parsing by name-to-address functions and references a document that I
was unable to find. I understand the "name-to-address functions" to
mean getaddrinfo. However I'm not clear why getaddrinfo should care
that scope zone index appeared first assuming the substring "ip6 ['/'
prefix]" were handled by a function similar in6_addr_pton above.
--Stephen
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian Haberman
Sent: Tuesday, April 05, 2005 7:00 AM
To: Joe Abley
Cc: grow@lists.uoregon.edu; ipv6@ietf.org; Pekka Savola
Subject: Re: grow: ipv6 anycast
Hi Joe,
On Apr 4, 2005, at 22:12, Joe Abley wrote:
>
> On 4 Apr 2005, at 08:35, Pekka Savola wrote:
>
>> This is a timely topic, because IPv6 WG just less than week ago
>> forwarded the revision of the addressing architecture to be published
>> as Draft Standard. (IPv6 WG is Cc:ed.)
>>
>> That draft,
>> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4
>> -02.txt still has the problematic wording wrt anycast addresses.
>
> Yes, I noticed that. I sent mail to the authors of that draft asking
> them for their thoughts on the anycast issue, but I haven't heard
> anything back, yet.
As a note, the current editor is only intermittently reachable due to
personal travel.
>
> Assuming there is consensus that v6 anycast for host-based services is
> a fait accompli, and that further prohibition is unnecessary, it would
> seem that adjusting the relevant paragraph in the revised (v4) v6
> addressing spec would be the cleanest way of proceeding.
My personal opinion is that the restriction should be lifted.
>
> However, although I think we had some kind of consensus to that effect
> in the grow meeting in Minneapolis, I haven't heard any opinion from
> those ipv6-wg folks who don't also participate in grow. Seems like
> some kind of hum from the ipv6 floor would be useful to hear (or, if
> no hum, active throwing of furniture).
>
I will pose that question to the group and report back.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
