[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Problem with draft-ops-endpoint-mib-05.txt
[Likewise, I have CC'ed this to the <mibs@ops.ietf.org>
list so that whoever this group of people is that I
just learned the existence of Friday afternoon know
what is going on.]
> Brian> Since addresses are assigned to interfaces,
> Brian> and site identifiers are assigned to interfaces,
> Brian> and interfaces have index values, I'm not sure
> Brian> I see why you're grouping the scope id with the
> Brian> address at all. It seems to me that these should
> Brian> always be set and retrieved independently,
> Brian> otherwise you could end up with conflicts (like
> Brian> someone assigning a scope-id/address pair to an
> Brian> interface where the address is site-local and the
> Brian> scope-id is for a site different from that
> Brian> assigned to the interface).
>
Juergen> Someone who needs to model IP addresses from a
Juergen> management perspective should not have to worry
Juergen> about the question whether he needs to expose
Juergen> a scope identifer or not. Using the
Juergen> (InetAddressType, InetAddress) pair should ensure
Juergen> that you do the right thing.
Well, I disagree. I think it's rather important from a management
perspective to understand scoped addresses properly and not just treat the
scope-id%address pair as a bigger address since the scope value has
different semantics. But I'm an IPv6 person, not a MIB person, so I can't
tell if your viewpoint comes from thinking in MIB terms or IPv4 terms. IPv4
viewpoints don't always apply to IPv6.
> Brian> Put another way, a scope-id/address pair is
> Brian> never an attribute of an interface, each is
> Brian> an independent attribute. But maybe I'm
> Brian> misunderstanding the intended use of this.
>
Juergen> The address is sometimes not unique. So we take
Juergen> the scope-id / address pair and get something
Juergen> which is unique.
Global addresses are unique. Scoped addresses are unique to their assigned
interface. I don't see why this is an issue given that addresses belong to
interfaces.
Juergen> (I think it is really a matter of the viewpoint.
Juergen> If you look at it from the perspective of an
Juergen> IPv6 packet, then the scope-id is really
Juergen> irrelevant. However, if you take the viewpoint
Juergen> of an external observer (who for example needs
Juergen> to understand firewall rules on a router), then
Juergen> the real address suddenly looks like a
Juergen> scope-id / address pair.)
Again, I think it is dangerous to think of a scope-id%address pair as just a
bigger address. So I wouldn't present them to network managers that way.
> Brian> Sure. I was just concerned that we might end up
> Brian> with the IETF specifying two conflicting formats
> Brian> for the textual representation of scoped IPv6
> Brian> addresses, which would be confusing to people.
>
Juergen> In which document do I find the definition of the
Juergen> other textual representation of scoped IPv6 addresses?
Well, that's the underlying problem here, there isn't one. At the moment,
the two existing IPv6 implementations that I'm aware of which fully support
scoped addresses use different formats. At the last IETF, one of these was
proposed in draft-ietf-ipngwg-scopedaddr-format-00.txt. This wasn't, uh,
universally loved, so the authors have been revising the format. The
current compromise which I expect to be in the next version of the draft is
<scope-id>%<address>. But again, until the IPng working agrees to the
thing, it's not carved in stone. Thus I find it premature for other group's
drafts to mention a format.
I hope you agree that this format is something that the IPng working should
decide.
>
> /js