Subject: Prefix Delegation Requirements and comparison

From: Ole Troan <[email-masked]>
Date: Thu, 18 Jul 2002 06:26:16 +0100

with regards to the PD discussion after Miyakawa-san's presentation.
I've added some requirements, and based on that started with a
comparison. I haven't read the router renumbering spec lately, so
please fill me in on that one.

Mechanisms
----------
Router Renumbering	    RFC2894
ICMP PD			    draft-haberman-ipngwg-auto-prefix-02.txt
DHCP PD			    draft-troan-dhcpv6-opt-prefix-delegation-01.txt
PPP/IPV6CP option	    -
Proxy-RA/Multi-link subnet  draft-ietf-ipv6-multilink-subnets-00.txt
RA option		    draft-lutchann-ipv6-delegate-option-00.txt

Requirements:
 draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt
-------------
A. L2 independent
B. Multi-access/Point to point
C. Support for Renumbering
D. Any prefix length can be delegated
E. Authentication
F. Negotiation, i.e requestor has a say
G. Other configuration options, e.g DNS, NTP with the same mechanism
H. Accounting (I did not understand this requirement)

                  | A |  B  | C | D | E | F | G | H | 
-----------------------------------------------------
Router Renumbering| x | both| x | x | ? | - | - |   |
ICMP PD           | x | both| x | x | ? | x | * |   |
DHCP PD           | x | both| x | x | x | x | x |   |
PPP/IPV6CP option | - | p2p | - | x | x | ? | * |   |
Proxy-RA          | x | p2p | x | - | - | - | * |   |
new RA option     | x | p2p | x | x | - | - | * |   |
-----------------------------------------------------

x - supported
- - not supported
* - could be supported, but perhaps not a good fit i.e DNS options in IPV6CP
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 07:55:02 +0200

In your previous mail you wrote:

   Mechanisms
   ----------

=> I believe this is the DHCPv6 option, there is a DHCPv6 subset too
(no draft?). IMHO the subset is better because it should not give
the funny current situation where nobody wants to use DHCPv6 for
its main purpose, address allocation, but for PD, DNS discovery, etc.

   PPP/IPV6CP option	    -
   
   Requirements:
   
=> just think your are an ISP (accounting is the politically correct
word for billing).

=> the x in E here seems too much (DHCPv6 is well known to provide
near no security (or please come with a security analysis of it).

   x - supported
   - - not supported

=> I agree (DNS options in IPv6CP) but I'm afraid many disagree...

Regards

[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 18 Jul 2002 15:04:40 +0900

Date:        Thu, 18 Jul 2002 07:55:02 +0200
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => I believe this is the DHCPv6 option, there is a DHCPv6 subset too
  | (no draft?). IMHO the subset is better because it should not give
  | the funny current situation where nobody wants to use DHCPv6 for
  | its main purpose, address allocation, but for PD, DNS discovery, etc.

DHCP is a "Host Configuration" protocol - it happens that with v4,
the address is the most fundamental piece of required configuration,
so DHCP is seen as an address assignment protocol.

But host configuration is what it is called and that is what it is.

For v6, address config can be done other ways, so it is entirely reasonable
that DHCPv6 will come to be used for almost everything else, but that.
That's OK.

However, we certainly be assuming that everyone will run DHCP, that's
one way to configure almost anything, but we always need the other
way, for sites where there is no DHCP.

kre

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 08:38:06 +0200

=> for me DHCP is the successor of BOOTP and the difference is
in the way to assign addresses... but I won't argue about this.

=> in our case it is far more than node configuration but
only the name is not so good.

=> it works but I can't qualify the situation of a large part of
a protocol is only a burden for current uses as OK.

Regards

---

From: "Aaron M. Smith"<[email-masked]>
Date: Thu, 18 Jul 2002 02:22:59 -0500

> please fill me in on that one.

I'm glad to see interest in generalizing beyond just the point-to-point case.
I'd like to have a solution that allows the requesting router to be more
than one hop away from the prefix delegator.  This would be useful for
deploying large scale networks.  This isn't a requirement for the isp-home
scenario that needs a solution in the short term, but if the solution chosen
for that is useful for the large network deployment scenario, so much
the better.

---

From: Robert Elz <[email-masked]>
Date: Thu, 18 Jul 2002 16:26:38 +0900

Date:        Thu, 18 Jul 2002 08:38:06 +0200
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => it works but I can't qualify the situation of a large part of
  | a protocol is only a burden for current uses as OK.

No question but that DHCP is a fairly heavy protocol - but that's at
the server end, and only needed if you actually want to use managed
address assignment.   If you do want that on your net, then all of
that baggage is required.

From the client point of view, using DHCP to get DNS server info, or
anything else like that is pretty lightweight, the rest of the protocol
can largely be ignored.   Even doing the client side of DHCP for address
assignment isn't all that burdensome.

So, it seems to me that there isn't much of an issue here really.

Note: I still don't believe that anyone should be required to use
DHCP (with or without the address assignment part) if they don't
want to - but on a net where the administrators want that level of
control, nodes should do the right thing and co-operate.

kre

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 12:51:51 +0200

I'm glad to see interest in generalizing beyond just the point-to-point case.
   I'd like to have a solution that allows the requesting router to be more
   than one hop away from the prefix delegator.

=> this is in fact supported by the same protocols that support multi-access.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 13:16:08 +0200

=> my concern is about the managed address assignement: it can be
needed for IPv4 where addresses are rare resources but *not* for
IPv6 where there are 2^64 addresses available per link. You can
believe in address registration for management, etc, but the reuse
of DHCP in the IPv6 world lead to a heavy protocol with a totally
useless main function, so I am *not* happy with this!

=> address assignment is not the good way to manage an IPv6 network,
address registration is simpler so better. Unfortunately my efforts
in the past (when I believed DHCPv6 should be used for itself :-)
to add this function in DHCPv6 failed... so we get a protocol
which shall not be fully implemented by major implementors (cf.
KAME and Microsoft) and is already in its 27th version after 7 years!

Regards

PS: I wasted in large amount of manpower in DHCPv6 implementations
but I lost my trust in the future of DHCPv6 when it was harshly
rejected at the Redmond IPv6 interim meeting for prefix delegation.
--------------------------------------------------------------------
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: "Toshi Yamasaki" <[email-masked]>
Date: Thu, 18 Jul 2002 20:55:53 +0900

Ole,

Thank you for your good summary and check list.

> H. Accounting (I did not understand this requirement)

This means "ISPs often want to log WHO used WHICH prefix from WHAT TIME to
WHAT TIME for to calculate fees or track who was abusing, and so on".
So your check list wil be:

                   | A |  B  | C | D | E | F | G | H |
 -----------------------------------------------------
 Router Renumbering| x | both| x | x | ? | - | - | ? |
 ICMP PD           | x | both| * | x | ? | x | * | x |
 DHCP PD           | x | both| x | x | x | x | x | x |
 PPP/IPV6CP option | - | p2p | - | x | x | ? | * | x |
 Proxy-RA          | x | p2p | x | - | - | - | * | - |
 new RA option     | x | p2p | x | x | - | - | * | - |
 -----------------------------------------------------

BTW, I like the idea of Proxy-RA(very primitive MSR?), but it is accurately
not a method for prefix "delegation" but for prefix "advertisement".

IMO,

- DHCP PD is the best for prefix delegation, where PE delegates prefix(es)
to subnet(s) behind CPE
- RA-proxy (or MSR) is the best for prefix advertisement, where PE advertise
prefix(es) to a subnet which is shared the PE-CPE link and links behind CPE

Here are my comments for each proposal:

- RR: Can we use it for over-site renumbering? I noticed many panelists at
IESG plenary said they don't know where to use RR
- ICMP PD: I loved it, but it's quite similar to DHCP PD for now. Many
implementors said it's easier to implement DHCP PD than ICMP PD, because the
draft is more mature.
- DHCP PD: I love it now :-) It satisfies the most requirements for us, who
want to start IPv6 access services tomorrow. I saw many running codes are
working with no problem.
- PPP/IPV6CP: Not bad. But we need another protocol when not using PPP,
anyway.
- Proxy-RA: I love it for MSR enviroments as I wrote above.
- new RA option: Too limited. Can be available only for P2P lnk, no method
for accounting and tracking.

--- Toshi Yamasaki / NTT Communications

---

From: Robert Elz <[email-masked]>
Date: Thu, 18 Jul 2002 22:32:46 +0900

Date:        Thu, 18 Jul 2002 13:16:08 +0200
    From:        Francis Dupont <[email-masked]>
    Message-ID:  <[email-masked]>

  | => address assignment is not the good way to manage an IPv6 network,
  | address registration is simpler so better.

This depends what kind of net you're attempting to run, and how.
Inside my house, I might want to group various different pieces of
furniture on the LAN into related address groups.   This allows me
to write firewall rules easily to grant similar access to all of the
chairs, without having to identify each one (they'll come from
different manufacturers, so the EUI won't help group them).

In this kind of environment I can be fairly confident that one of the
chairs isn't going to decide to simply configure itself a different
address to side-step my policies.  So as long as all the furniture talks
to my server to have its address allocated, I can assign addresses that
match my policies, and have the firewalls simply apply the correct
policies as soon as the node becomes active.

Certainly, address registration can be useful as well - but that's not
a configuration function, it is a post configuration function, so
arguably belongs elsewhere.   And also, certainly, not all nets require
all of this administrative baggage, and so it needs to be possible to
run a net with no DHCP servers at all.  So, while as an interim measure
until we get something better, doing some of the missing "extra" config
using DHCP, and not providing any alternative that really works might
be acceptable, longer term, we need methods for all of this that works
(which means not well known addresses, of any kind) without requiring
anything like DHCP.

kre

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Jul 2002 18:02:44 +0100

> => this is in fact supported by the same protocols that support

I'm afraid I don't see the connection. two out of the three proposals
use link-local multicast for delegator discovery, so without some sort
of relaying mechanism the requesting router and the delegating router
has to be on the same link.

even with a relaying mechanism you have to consider who and how you
get a route for the prefix injected into the routing system.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Jul 2002 17:57:26 +0100

if you don't mind, please let's try to focus on prefix delegation on
this thread. griefs with DHCP based address assignment can be taken on
the DHC list. I don't think we need to do the 'H' in DHCP means host
discussion again either.

cheers,
Ole

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 19 Jul 2002 12:52:51 +0900

>>>>> On Fri, 19 Jul 2002 12:51:58 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

>>>>> On Thu, 18 Jul 2002 17:57:26 +0100, 
>>>>> Ole Troan <[email-masked]> said:

> I free agree.
    ^^^^should be "fully"

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 19 Jul 2002 12:51:58 +0900

I free agree.

					JINMEI, Tatuya