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

From: Erik Nordmark <[email-masked]>
Date: Mon, 6 Dec 1999 10:51:26 -0800 (PST)

I never saw any discussion about this.

  Erik

------- Forwarded Message

From: Erik Nordmark <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 21 Sep 1999 18:22:11 -0700 (PDT)
Subject: Comments on draft-ietf-svrloc-ipv6-06.txt
Reply-To: Erik Nordmark <[email-masked]>

I don't understand the text in section 3.
Part of the problem is that terms like "link local advertisement" and
"routable addresses" are not defined.
(Is a link local advertisement an advertisement sent to a link-local
address or an advertisement that contains a link-local address?
All addresses are routable within some scope - does "routable"
mean "globally routable" or something else.)
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?
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.

In addition, the section needs to clarify the issues for multihomed
and multi-sited nodes (nodes connected to different sites) but
there is no need to forbid the DA or SA to be multihomed.
The constraint on multihomed and multi-sited nodes is that
a service: URL with a literal IPv6 address that is less than global scope
can only be advertised to the site (for site-local) or link (for link-local)
over which the IPv6 address was learned.
 
In section 5.1 is lists some multicast address with a wildcard 'X'.
What does this mean for an implementation? Is it supposed to
join the multicast group for all values of X (0 through 0xF)?
How does the client determine which value of X to use?

The examples in section 4 appear to use badly formed addresses.
It would make sense to use addresses which follow the EUI 64 format
i.e. with 0xfffe in the middle and with a non-zero subnet/SLA field.

Thus change
	fec0::a3f9:251c:1291:109d
to
	fec0::323:a3f9:25ff:fe91:109d

and change
	fe80::015a:93c0:d85d:b098
to
	fe80::a15a:93ff:fe6d:b098

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

------- End of Forwarded Message
>----------------End Forwarded Message----------------<

---

From: Erik Guttman <[email-masked]>
Date: Tue, 7 Dec 1999 12:23:38 +0100 (MET)

I thought I answered this...  I guess I never hit "Send Message"? :-)

See my comments below.

Erik

> Reply-To: Erik Nordmark <[email-masked]>

BTW:  Please refer to draft-ietf-svrloc-ipv6-07.txt - the latest draft.

> address or an advertisement that contains a link-local address?

Good question.  What I meant was an advertisement with a link local
address in it, not an advertisement by SLP to a link local address.

I will clarify this text in section 3.

  BTW, SLP can only 'advertise' DAAdvert messages using multicast.
  In experimental work ("Notifications and Subscriptions for SLP",
  draft-kempf-srvloc-notify-01.tx) service advertisements are also
  multicast.

Routable in this context means that the host advertising a service
has an address which is *not link local.*

I will clarify this text, too.

> mean "globally routable" or something else.)

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.

> of the packet to the scope of the address in the service: URL?

You mean service: URL, right?

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

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.

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.

I therefore agree with you that we should make the change, although
it does add complexity to the protocol.  
> over which the IPv6 address was learned.

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.

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

> How does the client determine which value of X to use?

Excellent question.  

I had assumed it would use the same scope as the address for the 
interface it was using.  The host could determine this by examining 
the address assigned to the interface.  But more needs to be said
than that.

I think that what we want to do is define

FF0X::116          Group for multicast SrvTypeRqst & AttrRqst messages
FF0X::123          Group for multicast DAAdvert messages and
                   multicast SrvRqst messages for "service:directory-agent"
FF0X::1:1000-13FF  Group for multicast SrvRqst messages besides
                   "service:directory-agent"

X can be 1 or 5.  X can only be 5 if a router advertisement in site local 
scope has been discovered (which is to say, can the interface support site 
local scope multicast?)

This is different than what has been written and assigned by IANA.
It is inappropriate for X to be more than 5 since SLP's applicability
statement specifies that SLP is to be deployed inside of sites.

I hope to implement this code early in the new year.

> 	fe80::a15a:93ff:fe6d:b098

Thanks for the corrections as well as the persistence.

I will make those changes for the next draft.  Let's try to 
iron out the issues soon.  

Erik

---

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

> 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 :-)

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

> You mean service: URL, right?

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

> service: URLs with link local addresses onto the link where the 

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.

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

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

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

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

   Erik

---

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