Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt

From: Richard Draves <[email-masked]>
Date: Mon, 25 Oct 1999 23:15:54 -0700

I like the idea of having a text representation for address plus scope-id.

I think the representation should specify the delimiter instead of leaving
it open.

I don't like the address@scope syntax. Winsock has a WSAStringToAddress
function that converts a string (address literal only, not name lookup) to a
sockaddr. It already supports the syntax address@port. So using @scope would
be ambiguous.

In our implementation we are using scope/address.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Oct 1999 21:24:48 +0900

>>>>> On Mon, 25 Oct 1999 23:15:54 -0700, 
>>>>> Richard Draves <[email-masked]> said:

> I think the representation should specify the delimiter instead of leaving

Agreed, but as you said below, each implementation would have its own
syntactical limitation on the delimiter, so I just proposed the
concept in the initial draft. After listening to other implementors'
opinion, I'll revise the draft with a specific delimiter (and
hopefully with a specific notation of scope_id).

> sockaddr. It already supports the syntax address@port. So using @scope would

Hmm, okay. In fact, @ would be ambiguous in another context; the
(traditional) telnet command using source routing, as I mentioned in
the Tokyo interim meeting. Maybe we should change the KAME's
implementation...

> In our implementation we are using scope/address.

What type of notation do you use as "scope"?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 1999 22:21:15 +0200

I believe we need a structure too in order to be able to deal with
a scoped address in context where a sockaddr_in6 is not needed
(for instance in RSVP or IKE tools, currently they use addresses
without scope (ie. in6_addr structures), this is obviously *wrong*).

Have you a proposal (we need interoperability)?

Regards

[email-masked]

PS: I like the '-' character as a delimiter ('@' is already used for
other purposes).

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Oct 1999 00:12:12 +0900

>>>>> On Tue, 26 Oct 1999 22:21:15 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> without scope (ie. in6_addr structures), this is obviously *wrong*).

Do you mean some API that would be used in the tools? If so, why not
just use sockaddr_in6 instead of in6_addr? Although I admit that
sockaddr_in6 has redundant fields for such purposes, the structure
already has *enough* fields.

> Have you a proposal (we need interoperability)?

So for now, I'm not convinced why a new structure should be introduced
(I don't oppose you, but I'm not sure yet).

> PS: I like the '-' character as a delimiter ('@' is already used for

Okay. Thanks for your opinion.

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 1999 19:15:19 +0200

> without scope (ie. in6_addr structures), this is obviously *wrong*).
   
   Do you mean some API that would be used in the tools?

=> yes, today these tools use in6_addr structures then scope ids are
lost and they work only on a home with only one interface (ie. only
where there is no possible ambiguity.

   If so, why not just use sockaddr_in6 instead of in6_addr?

=> because of space. You should ask why in6_pktinfo is not replaced
by sockaddr_in6 too (because the in6_pktinfo structure is exactly
what is needed :-).

   Although I admit that sockaddr_in6 has redundant fields for such
   purposes, the structure already has *enough* fields.

=> too many fields...

   
=> I'd like to have an answer from someone involved in a RSVP or IKE tool
(I know some of them read the list). I think one of the problems is
(was?) the lack of a textual form for a scoped address.

Thanks

[email-masked]

PS: my purpose is not to flame RSVP/IKE/... tool writers but in such
low layer tools (some parts are in kernels) there are some reasons
to use addresses in place of socket addresses with redundant fields.

PPS: my current proposal is:

struct in6_scaddr {
	struct in6_addr sc6_addr;
	uint32_t sc6_scope_id;
};

---

From: [email-masked]
Date: Thu, 28 Oct 1999 07:07:39 +0900

>	struct in6_addr sc6_addr;

	Do we really need to standardize this structure?  Application writers
	need to define by their own anyway.  People who touches IPv6 header
	(for example) needs to handle in_addr and its associated scope very
	carefully, anyway (on-wire form is always in6_addr).

itojun

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 Oct 1999 20:35:20 +0200

>	struct in6_addr sc6_addr;
   
   	Do we really need to standardize this structure?

=> as usual this the best way to interoperability.

        Application writers need to define by their own anyway.

=> I think application writers like standard libraries and all the things
where they can get a wheel without to have to rebuild a new one.
 The real question is whether there is enough interest in this.
(another idea is to help to remember a link-local address without the
interface is useless, for instance a SADB entry definition with addresses
but no scope will give troubles with link-local addresses...).

Regards

[email-masked]