Subject: solicit-ID

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Jun 2000 17:15:48 +0200

There is no rationate for the new solicit-ID introduced by the last I-D
(draft-ietf-dhc-dhcpv6-15.txt). What is the need for "matching Advertise
messages to the sent Solicit message"?

Regards

[email-masked]

PS: in the revised IPng WG charter you can find in new proposed items:
    - Support for multi-link subnets (single subnet spans multiple links)
then as DHCPv6 doesn't support this, a statement should be added in specs.

---

From: Jim Bound <[email-masked]>
Date: Mon, 26 Jun 2000 23:44:05 -0400

Hi Francis,

>From 10.3.1

   If the client is prepared to process multiple Advertise messages
   in response to its Solicit message, the client will set the
   Solicit-ID field to 1.  Every time the client initiates a new server
  solicitation attempt (not a retransmission), the client increments
   the Solicit-ID by one.  If the 9-bit field rolls over to 0, then the
  client sets the Solicit-ID to 1.  A client which will only accept
   the first Advertise message it receives leaves the Solicit-ID field
   initialized to zero.

The idea was that the client may talk to different servers after a
new solicit takes place?

Comments?

>then as DHCPv6 doesn't support this, a statement should be added in specs.

I saw that and see my mail the IPng list.  I have no issue with subnets
spanning multiple links if we can figure it out.  But I do strongly
object if the idea of a global address is gone!!!  If that happens
working on anything for IPv6 is just stupid the whole architeture is
broken.  I don't think that will happen.  DHCPv6 must assume as we state
in the draft that a server spanning multiple sites must use global
addresses today, likewise we assume global addresses are in fact unique.
IPng has not stated they will break that model.

Also we cannot base our efforts to get to PS on IPng Working Group
milestones.  

regards,
/jim

---

From: "Michael W. Carney" <[email-masked]>
Date: Tue, 27 Jun 2000 10:24:37 -0700

Hi Francis,

> messages to the sent Solicit message"?

Thank you, francis - if we don't include the rational for a feature (and
it
isn't clear), we have to either clarify it or remove it from the
protocol.

The reason we added the solicit ID is to enable clients to identify
advertisements generated by specific solicits. There are two kinds
of clients:

1) Simple - These clients accept the first advertisement received in
response
to a solicit. They ignore any other advertisements that are received.

2) Sophisticated - These clients are prepared to process multiple
advertisements.
They may set the 'P' bit to request that servers return subnet prefix
extensions
for those networks on the client's link that the server is configured to
manage.
They may have multiple solicitation events pending.

The solicit ID is important for the second type of client. Since they
are
prepared to accept multiple advertisements, they need to be able to
differentiate
between advertisements received due to earlier solicitations vs those
due the the most recent solicit (which is why the solicit id is
incremented whenever a new solicitation is generated, not when one is
retransmitted). In short, it lets
the client connect advertisements to the solicitation event that
generated them.

Based upon the application requirements, the same dhcp client may
operate as
both types - e.g., I want to find any server, or I'm shopping for a
server that
can give me a network address of sufficient scope needed by the
application.

> then as DHCPv6 doesn't support this, a statement should be added in specs.

Where can I find details about the rational for this topology?

Thanks,

Mike Carney

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Jun 2000 10:03:58 +0200

=> the 'P' bit seems to be the key.

=> I believe you'd like to avoid some race conditions in case of
a solicit during a renumbering. I think renumbering events have a
large time scale but solicit/advertisement sequences with off-link
servers must be done through relays (on the contrary request/reply
can be done directly using global addresses for instance) then
races can occur...

   
=> there are some messages about this in the IPng mailing list.
Multi-link subnets are in the revised charter and are used in
draft-nordmark-ipv6-aaa-hooks-00.txt where they gives some kind
of mobility supports with host routing.

Regards