Subject: Ordering of % and / in RFC 4007

From: "Steve Cipolli" <[email-masked]>
Date: Wed, 6 Apr 2005 10:09:22 -0400

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-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Tuesday, April 05, 2005 7:00 AM
To: Joe Abley
Cc: [email-masked]; [email-masked]; 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 07 Apr 2005 15:59:03 +0900

>>>>> On Wed, 6 Apr 2005 10:09:22 -0400, 
>>>>> "Steve Cipolli" <[email-masked]> said:

> zone index before the prefix in the textual representation?  

(snip)

> prefix]" were handled by a function similar in6_addr_pton above.

The intended function is getaddrinfo, yes.  And the expected usage in
this case is as follows:

(assume variable "prefix" points to a string like "fe80::%5/64")

	char *addr, *p;
	int plen;

	p = strchr(prefix, '/');
	*p++ = '\0';
	getaddrinfo(p, NULL, hints, res);
	plen = atoi(p);

(Note: error handling or proper handling of constant variables are
ignored for simplicity)

Then
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_addr = fe80::
  ((struct sockaddr_in6 *)res->ai_addr)->sin6_scope-id = 5
  plen = 64

If we represented the scoped prefix as, e.g., "fe80::/64%5", the above
code couldn't be that straightforward.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]