Subject: RE: Ordering of % and / in RFC 4007

From: "Steve Cipolli" <[email-masked]>
Date: Thu, 7 Apr 2005 11:13:00 -0400

The code below would be straightforward if the "/64" prefix were
accepted by getaddrinfo.  

Besides, I don't think the textual representation should be defined to
make only Basic Socket API functions straightforward.  IMHO, the order
should be logical on its own.  The prefix is clearly more tightly
related to the IP address (in6_addr) and the scope zone index is clearly
(by virtual of the fact that scope_id is in sockaddr_in6) related to the
transport address.  So the textual representation as it stands now mixes
IP address and Transport address information.

--Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Thursday, April 07, 2005 2:59 AM
To: Steve Cipolli
Cc: [email-masked]
Subject: Re: Ordering of % and / in RFC 4007

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

> Can someone explain the rational for why RFC 4007 mandates the scope 
> zone index before the prefix in the textual representation?

(snip)

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

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]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Apr 2005 08:30:38 +1000

> IP address and Transport address information.

	No they are both properties that can be associated with a
	address.  If anything the scope ties closer than the prefix
	as a link-local address or prefix is meanless w/o the scope.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]