Subject: draft-ietf-dhc-dhcpv6-15.txt

From: Francis Dupont <[email-masked]>
Date: Sat, 20 May 2000 18:01:26 +0200

The last DHCPv6 I-D, draft-ietf-dhc-dhcpv6-15.txt, uses many times
the false assumption that a subnet prefix identifies a link but
more than one link can share a subnet prefix (look at for instance
draft-nordmark-ipv6-aaa-hooks-00.txt section 12 "Open issue" page 11,
the problem is a subnet prefix can be "off-link", RFC 2461,
section 4.6.2 Prefix Information "L flag", page 30).

Regards

[email-masked]

PS: I don't know how to fix it for all cases because interface indexes
are local to a node (ie. to add an interface index in some messages
will fix the relay -> client transmission (as I have already suggested)
but not the binding index (two different nodes can have the same link-local
address and share the same subnet prefix if there are not on the same link
then link-local address + subnet prefix is not enough and for instance
11.6.1 Receipt of Request messages "the server checks if a binding
already exists for the client" can give the wrong answer...)

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 20 May 2000 10:19:53 -0700

Hello,

Then I would suggest that the DHCPv6 specification make a
statement of applicability.  Such links should be either be
administered to make the requirements for DAD and relay
connectivity come true, or else be ineligibility for configuration
via DHCPv6.

How many designs have been encouraged by allowing
multiple isolated links to share a global IPv6 address
prefix?

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 20 May 2000 20:04:20 +0200

In your previous mail you wrote:

   Then I would suggest that the DHCPv6 specification make a
   statement of applicability.

=> I believe that you propose to restrict DHCPv6 to situations
where no shared subnet prefix is used across multiple links?

   Such links should be either be
   administered to make the requirements for DAD and relay
   connectivity come true, or else be ineligibility for configuration
   via DHCPv6.
   
=> I don't understand this...

=> the links have not to be isolated for sharing a common subnet prefix.
I believe a case of application of "off-links" is a star of radio
networks with a central router using a common prefix and Eric's
host routing hook as a kind of micro-mobility. The only issue there
is DAD (ie link-local multicast won't spread) and a nice solution,
address allocation management by a DHCPv6 server, will not work
because DHCPv6 can't deal with "off-link" prefixes...
(the idea is to use the DHCPv6 server knowledge in order to detect
and/or avoid duplicates between links)

Regards

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 20 May 2000 15:04:49 -0700

Hello Francis,

> where no shared subnet prefix is used across multiple links?

That seems almost reasonable to me, except that I would rather say
that DHCPv6 entities should not be affected by the disconnected
nature of the link.

> => I don't understand this...

It is almost like saying the same as the above in a different
way.  Either a link can do DAD, or the administrator can
put in some bridge or other equipment to make it do DAD.
And, if a relay is supposed to be on the same link as the
DHCP client, the administrator has to make it look that way
even if the link is partitioned.

Otherwise, I suspect that the problem is too hard.  And,
do you already admit that no one has solved it for stateless?

> and/or avoid duplicates between links)

This is fine with me, but it amounts to an agreement to my
suggested requirement:
>   Such links should be administered to make the requirements
>   for DAD and relay connectivity come true

It has to be done by administration, because as you point
out it is unlikely to be done by any natural means of
communication.  In some nightmare scenario, we could
go about defining a new numbering space adjunct to the
basic routing prefix, sort-of what has been suggested for
site-local prefixes.  I'd hate to see that.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 21 May 2000 15:06:24 +0200

=> there are some situations where the "off-link" property doesn't come
from the disconnected nature of the link (a case where there is near
no good solution) but does come from the spread of the subnet prefix
over a set of (interconnected) links. In this (second) case DHCPv6
is a good central management tool and I'd like to be able to use it...

   
   
=> my concern is not about partitioned links.

   
   communication.

=> yes, for me neighbor discovery DAD is obviously restricted to the
link then with more than one link something else must be used.
There are two immediate solutions:
 - use a multicast service at a larger scope (distributed solution)
 - use DHCPv6 because DHCPv6 has a global knowledge of all the used addresses
   when all nodes register them.

   In some nightmare scenario, we could
   go about defining a new numbering space adjunct to the
   basic routing prefix, sort-of what has been suggested for
   site-local prefixes.  I'd hate to see that.

=> we can have "off-link" prefixes without a parallel address space like
the site-local one (I don't like it too :-). Eric's "Host Routing" is
a good example...

Regards

[email-masked] (no more @inria.fr)

---

From: Jim Bound <[email-masked]>
Date: Mon, 22 May 2000 08:45:58 -0400

hi francis,

i would like to approach this discussion differently with you OK.

I do not see your issue for DAD, Stateless, etc.  If the prefix and sum
total of bits is equivalent to a GLOBAL IPv6 address.  

For IPv6 aggr addresses using a 64bit prefix len with the prefix and the
prefix is global then the prefix does identify a link or the
administrative domain has made an error.  Similar to assigning 2 IPv4
addresses to a node in an admin domain.

Lets just discuss global addresses first.

Do you agree with the above.

thanks
/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 May 2000 15:30:08 +0200

For IPv6 aggr addresses using a 64bit prefix len with the prefix and the
   prefix is global then the prefix does identify a link or the
   administrative domain has made an error.

=> this is not what is written in RFC 2461 and 2462.
Eric's draft-nordmark-ipv6-aaa-hooks-00.txt gives an example of
a prefix shared across several links (and where DHCPv6 can provide
a good answer to open issues).

Regards

---

From: Jim Bound <[email-masked]>
Date: Mon, 22 May 2000 10:13:12 -0400

Francis,

You did not answer my question?  It is important?  

Let me try another way?

Do you believe global addresses are unique because of the IPv6 Prefix?

yes or no?

then we can discuss non global addresses.

p.s. I will look at Eric's draft again too.  

thanks
/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 May 2000 16:40:57 +0200

=> I don't understand your question and its relationship with our issue.

   Let me try another way?

   yes or no?
   
=> the problem is not here, you can share a (global) prefix and still have
unique addresses. Of course DAD will not detect duplicate between links
but there is a good tool which could do that: DHCPv6!

=> let us stay with global addresses.

=> you should read it because it is the best example of "off-link"/shared
subnet prefix usage.

Regards

---

From: Jim Bound <[email-masked]>
Date: Mon, 22 May 2000 11:37:21 -0400

Francis,

>=> I don't understand your question and its relationship with our issue.

What I am trying to do is use the logic model often referred to in
computer science and physics called the "staircase of abstraction".  I
am well aware of the problem and at Compaq we ran such tests and even
tried to repair links at the link-layer to understand the effect to the
prefix.  

The **EFFECT** to this problem is different for global vs site-local. I
first want to deal with Global to make a scientific point per IPv6
architecture.

>but there is a good tool which could do that: DHCPv6!

Hold on here in the IPv6 Addressing Architecture it states clearly: 

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

THis is the model dhcpv6 is trying to solve now.  Clearly we have
work-in-progress in the IETF for IPv6 and we will for the next decade
just like we do for IPv4 as we speak.

We do not have to fix this problem right now for DHCPv6.  

ALso we should not support the idea of an interface index in any
protocol.  An address should define its scope for global.  Site is
work-in-progress on ipng and semantics are not a done deal.  DHCPv6 must
move forward for what is deployed today.

>=> you should read it because it is the best example of "off-link"/shared

I have read it twice now.  And I question whether it is allowed but that
is an IPng discussion.  The routing ramifications are phenomenal and I
strongly beleive DHCPv6 should not fix this problem when there is NO
CONSENSUS at all in the IETF on solving this problem in this manner.

regards,
/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 May 2000 19:45:40 +0200

=> Eric's proposal shows a case where a subnet prefix is not shared
by many links by accident, ie. because a link has been broken in many
(in general not connected) parts. His proposal is more similar to a CLNP
network with an address per node, ES-IS and IS-IS for routing (this kind
of topology has very different properties).

   

   
=> then your proposal is to add a statement that DHCPv6 works only
when a subnet prefix is never associated with more than one link?
I've no objection if it is added before to be published as a proposed
standard...

   protocol.

=> I just proposed to add a scope ID (aka an interface index in this case)
to link-local addresses in order to partially solve the problem with
shared prefixes. If shared prefix support is a non-goal then there is
nothing to fix.

   
=> you're closing the door, I'd like to get Eric's opinion about this issue
because it will be hard to reopen the door after (and I like Eric's
host routing :-).

Regards

---

From: Jim Bound <[email-masked]>
Date: Mon, 22 May 2000 22:49:33 -0400

>of topology has very different properties).

Erik's proposal shows no such case but makes an assumption I don't agree
with in the intro of the spec about ND regarding he "L" bit.  But lets
not discuss Erik's proposal here OK.

We have to stop messing with Ipv6.  Site-Locals and Multiple Prefixes
across links are at best research areas.  We have to do with DHCPv6 what
we did with IPv6.  Get a proposed std out, implement it and make sure
its extensible.  We will evolve DHCPv6 and IPv6 and Mobile IPv6. But we
have real customer that want all three right now in mulitple markets.

   

   
>I've no objection if it is added before to be published as a proposed

I would rather not as I argue that IPv6 DOES NOT PERMIT MULTIPLE
PREFIXES across LINKS of the EXACT number of BITS.  If it does then IPv6
is broken and needs serious fixing.  

What we can do is state that DHCPv6 is applicable to such and such as
Charlie suggested and what we do with most routing protocols today in the
IETF.

>shared prefixes. If shared prefix support is a non-goal then there is

If Ipv6 will require a scope-id to get link-locals to be unique on a
link because of prefixes being multi-lingual then IPv6 is totally
broken.  For DHCPv6 we assume a prefix+link-local is unique if that is
not true then DHCPv6 will not work.  I believe it is true today.
There is no way to gurantee that two scopes will not collide either.
The problem if we do not assume what is specified in the Addressing
Architecture TODAY is out of scope.

   
>because it will be hard to reopen the door after (and I like Eric's

I am closing the door yes.  The door is not open.  Erik's work is a
first draft and thats all.  It will take at least 1.5 years to parse we
need to move DHCPv6 forward.  

The addr arch spec supports what I am saying 100%.  Does that mean in
the future we can do this, well that will be a long debate.  Same for
the use of Anycast Addresses for Hosts and not just routers.  Ipv6 will
evolve but trying to hack in what is unknown nor has consensus into
DHCPv6 at this point is not a good idea and not a reason to hold up
DHCPv6 to move forward.

regards,
/jim

Regards