Subject: Comments on IPv6 Draft

From: James Kempf <[email-masked]>
Date: Tue, 10 Aug 1999 09:47:41 -0700 (PDT)

Hi Erik,

Thanks for pushing this draft forward.

I've got two comments:

1) What is the IESG policy with regard to updating RFC's that have
been superceeded? I don't know whether RFC 2608 obsoletes RFC 2165, but
the question does come up related to the proposed IPv6 update for SLPv1.
If the policy is affirmative, the other question is whether it is
desirable.

2) I've never been a fan of the SLPv1 multicast range for service
types, and I'm distressed to see it reappear for SLPv2. I don't feel it
makes much sense from a design standpoint, because it's not clear
to me that the amount of multicast traffic for SLP for a particular 
service type in a network without DAs requires the complexity 
necessary to implement this scheme. 

If any sort of multicast address partitioning should occur, I believe
it should be based on the scope. This would align it more closely
with the multicast address allocation architecture, allowing a
scope-specific address to be allocated (if I understand the MAAA correctly).
Scopes seem to me the logical partitioning mechanism for sectioning
what SAs should listen for which requests. 
		jak

---

From: Terry Lambert <[email-masked]>
Date: Tue, 10 Aug 1999 10:35:56 -0700

> Thanks for pushing this draft forward.

[ ... ]

> 2) I've never been a fan of the SLPv1 multicast range
>    for service types, and I'm distressed to see it reappear
>    for SLPv2. I don't feel it makes much sense from a
>    design standpoint, because it's not clear to me that
>    the amount of multicast traffic for SLP for a particular
>    service type in a network without DAs requires the
>    complexity necessary to implement this scheme.

I think this reappearing in SLPv2 is in recognition of
limitations of the NT multicast implementation.  Specifically,
the IP_MULTICAST_IF socket option doesn't seem to be
implemented correctly in any NT, as of NT 4.x.

> If any sort of multicast address partitioning should occur,
> I believe it should be based on the scope. This would align
> it more closely with the multicast address allocation
> architecture, allowing a scope-specific address to be
> allocated (if I understand the MAAA correctly). Scopes seem
> to me the logical partitioning mechanism for sectioning

Scopes seem to me to be the idea of LANMan "workgroups"
creeping into somplace they don't belong (i.e. the
Internet).

I have a real problem with requiring a scope, at least
without use of the TTL=255 hack, so that a device that
doesn't know the "name" of the wire can discover it.  I
guess I just hate the idea of having to configure a scope
into the front panel of a device with an embedded SA, e.g.
a printer.  I can imagine the pain this would entail on,
say, an HP LaserJet 5Si with SLP SA-enabled ROMs.

Not that the issue of scopes vs. multicast partitioning
have anything to do with this draft, which in Section 5.2
claims:

    SLPv2 for IPv4 specifies only one multicast address.

Which I think puts your problem to rest, except as regards
backward compatability.

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: Erik Guttman <[email-masked]>
Date: Tue, 10 Aug 1999 20:11:10 +0200 (MET DST)

> If the policy is affirmative, the other question is whether it is

I will check on this policy question.  One possibility is that we
state that there are no indicated "SLPv1 modifications for IPv6",
that people are dissuaded for doing this development at all.  

> necessary to implement this scheme. 

The question whether there will be enough traffic to warrent the use
of multiple addresses is empirical.  IPv6 has sufficient address range
to support this feature.  

One advantage of this scheme is that small devices which offer only
a single service will not have to process most SLP multicast requests.

Further, it may be the case that there will be *many* small services
on networks with no administration (such as scopes, or deployment of
DAs) in the future.  This feature makes it feasible that SLP over IPv6
will successfully scale to those environments.  Until we actually build
them, we won't know for sure.

Finally, this feature has a precedent in another IPv6 discovery protocols.
See RFC 2461, page 9, solicited-node multicast address calculation 
algorithm.  This is a draft standard.

It really doesn't require any additional complexity from the UA side
(the destination address is computed by a single hash rather than a
fixed MC address).  The only additional complexity is on the side of 
the SA which must join multiple groups depending on what services
it advertises.  I note that there is no *harm* done if the SA fails
to leave groups which it no longer advertises so this management is
not actually that complicated (every time there is a registration,
simply join the indicated group).

Erik

---

From: Erik Guttman <[email-masked]>
Date: Tue, 10 Aug 1999 20:28:01 +0200 (MET DST)

> implemented correctly in any NT, as of NT 4.x.

The reason that SLPv2 over IPv6 is specified to use the range of
MC addresses is that it is (arguably) a good engineering design 
decision.  It has nothing to do with NT.

We could not use a range of MC addresses in SLPv2 over IPv4 because
we were constrained (rightly) to use Administratively scoped mc addresses,
and in this space we only had the option of getting 1 static (relative)
address - not 1026, as specified in SLPv1.  These addresses are already
allocated in the IPv6 range, and there is no penury of addresses there
as in IPv4.  Nor were scoped MC addresses an afterthought in IPv6 as
they were in IPv4.

The reasons for wanting the range of addresses remains valid for
SLPv2:

  - It reduces the burden on listening SA devices (they only receive
    a fraction of all multicast requests, and most of those they
    receive are relevent for them to process)

  - It is a lightweight solution to implement

  - It is an appropriate mechanism for use by a discovery protocol
    on IPv6 (see calculation of solicited address multicast addresses
    in Neighbor Discovery / Stateless Addrconf in IPv6).  This adds
    to the scalability of the protocol

> > Scopes seem

Please note that scopes in the sense Jim mentions them are multicast
scopes, not SLP scopes.  These are disjoint.
 
> say, an HP LaserJet 5Si with SLP SA-enabled ROMs.

My idea is that you can either use DHCP to configure these scopes,
or in the future, when we have MADCAP, you can discover the admin-
istrative multicast scopes you are in, and use these as your default 
SLP scope assignements.  That is, in the future, SLP scopes and 
multicast scopes can be *identical*.  This is predicated on the
deployment of MC scoping and MADCAP.  It is, as I say, just an
idea of mine which has not been discussed by the WG formally.

In the absense of administrative configuration, the embedded
SA will at least be configured to use the "default" scope and
the administrative local scope 239/8 - which is to say, it will
use 239.255.255.253 as its MC address.

Erik

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Aug 1999 07:25:34 -0400

> If the policy is affirmative, the other question is whether it is

I think its the WG's call on what to do. If there is value in having a
v6 version of the SLPv1 spec, then that should be done. For example,
if SLPv1 was widely deployed, it might make sense to tweak existing
implementations to v6-enable them rather than build SLPv2.

At the same time, I think it is a legitimate question to ask whether
IPv6 should support SLPv1 at all, given that SLPv2 is done and SLPv1
for v6 was never done.

> necessary to implement this scheme.

I think Erik sums up the issues pretty well. Bottom line question is
whether the extra complexity is worth the improved scaling
capabilities.

> it should be based on the scope.

Can this work though? Can't SLP packets contain info relating to more
than one scope? If there are multiple scopes, they somehow have to map
to one multicast address (and that address must be one all the
relevant DA/SAs are listening to).

Thomas