RE: Problem with draft-ops-endpoint-mib-05.txt

[Brian Zill <bzill@microsoft.com>]

> From: Juergen Schoenwaelder
> 
> Lets stop the discussion whether an IPv6 address plus
> scope-identifier is some sort of an address or not.

Okay, I'll assume you folks know better about what you need here.

> Can you summarize the reasoning why the scope identifier
> should be in front of the IPv6 address? Why does
> <address>%<scope-id> not work?

In the interest of full disclosure, I should mention that this was/is a
matter of some debate in the IPng working group.  Since I'm in the "in
front" camp, I can present that argument.  Basically, it comes down to three
things: conflicts with other things that come after an address, "big-endian"
consistency, and aesthetics.

Conflicts: We already need to support the <address>/<prefix-length> format
for specifying prefixes.  Also, many things use conventions like
<address>:<port> or <address>@<port> which have already caused difficulties
for various reasons.  Putting the scope-id first avoids these issues.

Big-endian: Addresses are big-endian (most significant part comes first).
The scope-id is more significant than the address since it defines the area
an address is meaningful in.  Putting the scope-id after would be like the
American Month/Day/Year convention with its mixed order instead of the saner
European Day/Month/Year convention which is pure little-endian.

Aesthetics: Purely subjective.  Either you have taste, or you don't :-)

> Brian> But again, until the IPng working agrees
> Brian> to the thing, it's not carved in stone.
> Brian> Thus I find it premature for other
> Brian> group's drafts to mention a format.
> 
> Perhaps it is a sign that IPng folks need to agree
> a little bit faster. ;-)

Yes, this is something that should have been decided years ago and was
overlooked (or avoided) until people started building implementations with
full support for scoped addresses and needed to do something.  But pointing
fingers now seems unproductive, so I'm trying not to do that.

[Combining the two messages...]
> The DISPLAY-HINT goes works with the ordering of the
> bytes in on the wire. We need 16 or 20 bytes to represent
> global and non-global addresses. The only reasonable way
> in the current SMIv2 is to have the optional bytes at the
> end. Sure, you can call the current SMIv2 (STD 58) broken.
> But that won't help to solve the problem since it is a
> standard. (BTW, even the struct sockaddr_in6 puts the
> sin6_scope_id field "behind" the sin6_addr field.)

If I understand you correctly, the problem is that the DISPLAY-HINT
specifies the order of the bytes on the wire and also does double-duty as a
hint for how to display the value textually (something to fix in SMIv3 I
guess).  The former usage I'm not concerned about, I'm only worried about
the latter.  (The order of the fields in a sockaddr_in6 doesn't affect the
textual representation, it's only the binary representation - and it's also
not an IETF standard.  The reason the sin6_scope_id was put on the end was
to allow for backwards binary compatibility with earlier incarnations of
sockaddr_in6.)

I don't know enough about this to recommend a work-around.  Is it possible
to add a notation stating that for this definition, only the wire
representation meaning is intended to apply and that one should read the
eventual ipngwg draft on this for the textual representation?

--Brian

> 
> /js
> 
> -- 
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 
> Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>