Subject: Re: FWD: Comments on draft-ietf-svrloc-ipv6-06.txt (Fwd)

From: Erik Nordmark <[email-masked]>
Date: Tue, 7 Dec 1999 18:25:07 -0800 (PST)

> > Date: Tue, 21 Sep 1999 18:22:11 -0700 (PDT)
> > Subject: Comments on draft-ietf-svrloc-ipv6-06.txt
> 
> BTW:  Please refer to draft-ietf-svrloc-ipv6-07.txt - the latest draft.

My time machine was broken back in September (in the shop) when I sent
these comments so I couldn't read the -07 draft which is dated in October :-)

> Routable means not link local.  For instance, site local scope
> addresses are routable.  These addresses would be perfectly
> fine to put into a service URL.

OK. I don't know of a term that would make sense (routable isn't it -
link-local addresses can be forwarded by routers as long as
they don't leave the link so they are indeed routable).
Perhaps just saying "except link-local"?

But this brings up a question on IPv6 in a zeroconf environment.
Wouldn't there be cases when there is no router thus the only
addresses in use would be link-local? I assume I should be able to use
SLP in such a case.

> > But the more fundamental question is the need for these
> > restrictions.
> > Isn't it sufficient to tie the scope of the destination address
> > of the packet to the scope of the address in the service: URL?
> 
> You mean service: URL, right?

Huh? I said "service: URL" so what is the question?

> > Thus the limitation would be that a server: URL can not contain
> > a literal IPv6 address which has a scope which is smaller than the
> > scope of the IPv6 destination address.
> 
> That is true, but we wanted to be more conservative.  It complicates
> the protocol to require DAs and SAs to keep track of which interface
> a request arrives on and what scope the requester's address has.  The
> SA or DA would have to answer differently in different situations.  
> It is worse for a DA, as it may be multihomed.  The DA may only forward
> service: URLs with link local addresses onto the link where the 
> advertisement was made. 

Same complexity applies to site-local addresses for multi-sited nodes.
I assume we want to support link-local addresses with SLP so we might as
well bite the bullet and figure out how to handle scope zone boundaries.

I could be confused but the way the spec is currently written it seems to 
prohobit me from building an SA or DA that is aware of the scope zone
boundaries. I think the document should instead state that if
the SA or DA is not aware it needs to do X and Y to be conservative and
that aware SAs and DAs need to make sure they get V and W correct.

> Alain Durand advised me that this was both too complicated and would 
> lead to faulty implementations.  Thus we decided for very conservative
> language in the draft to prevent the possibility of link local addresses
> in service URLs leaking beyond their scope.

But this is akin to saying "we are not going to tell you what the issues
are in building a correct zone aware application but instead mandate
that should an implementation must never be built". Or did I get this
wrong?

> As Jim Kempf points out, we can't really ignore this issue even for 
> IPv4.  If a DA or SA is multihomed it has the potential to release
> inappropriate numerical addresses in URLS it sends in SLP messages.

Sure. And in IPv4 there is no way for it to tell if an address
has limited scope. The best you can do is if sending an SLP message on
a given interface make sure you use IP addresses associated with that
interface, since IP addresses from another interface might not be reachable.

> I therefore agree with you that we should make the change, although
> it does add complexity to the protocol. 

You don't have to mandate zone awareness. Just point out the issues
and constraints for being zone aware and the issues/constraints for a
conservative and presumably simpler non-zone aware implementation.

> If we can require that DAs and SAs MUST NOT respond to a request from
> address A with a service: URL which has a numerical address which is
> not in the same scope as A, then I agree.

That would be fine except the distinction between a scope (such as site-local)
and a scope zone (a particular site). You need this check to apply to zones.

> Would this imply that a SA would have to advertise multiple times in 
> different scopes?

   Erik

--------------------------------------------------------------------
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: Erik Guttman <[email-masked]>
Date: Wed, 8 Dec 1999 11:31:39 +0100 (MET)

> Perhaps just saying "except link-local"?

How about 'non-link-local addresses'?

> addresses in use would be link-local? I assume I should be able to use

I believe the answer here is that SAs and DAs must always advertise
on the link local scope whether or not they have non-link-local addresses
assigned to their interfaces.  
 
> that aware SAs and DAs need to make sure they get V and W correct.

OK - let's try to do this.

> that should an implementation must never be built". Or did I get this

No you aren't.  You've persuaded me it is worth while (as it removes
restrictions, though it adds complexity and risk of propogating addresses 
beyond their scope).
 
> conservative and presumably simpler non-zone aware implementation.

I'll give it a try.  I'll count on you to help me get it right :-)
 
Erik