Subject: Prefix delegation options

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Mar 2002 00:55:41 +0200 (EET)

Hi,

I wanted to add a few cents to the discussion, triggered by Francis saying
we're going nowhere :-)

- router renumbering hasn't been made to work yet, so I doubt that's a 
good option

- pppext might be workable for PPP connections, and is a valid mechanism 
especially if there is no simple alternative (e.g. if the only alternative 
is full statefull DHCPv6).

- dhcpv6 will work ok, I think, but is a bit complex for being usable 
in every scenario

- APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return 
message)

- RA (Lutchansky) is a nice hack, kinda works with hacking.

So, IMO the real mainstream solutions will either be:

 - A combination of APD + RA (Lutchansky), closer to APD
 - DHCPv6 

I think we don't end up with just one mechanism due to different 
requirements.

The choice will be partially dependent on the fact whether configuring the
router and nodes (DNS, NTP, ...) will be necessary and/or how. These are
two different problems though.  DNS etc. only make sense *after* obtaining
the prefix.

Note that IMO, configuring these with "stateless DHCPv6" but obtaining the
prefix with e.g. APD makes perfect sense -- there might be reluctance to
implement full DHCP, or even the minimal set of "stateful" DHCP.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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: Fri, 22 Mar 2002 00:16:42 +0100

In your previous mail you wrote:

=> my comment was about the addressing architecture, for the prefix
delegation we have a promise of a requirement document.

=> this was rejected at the interim meeting too.

=> PPP is too restricted. We are still trying to use other things than PPP
for standard network access control, so IMHO it is a bad idea to rely
again on PPP.

=> full statefull DHCPv6 (to reuse your term) is far too heavy.
The stateless new DHCPv6 is not yet specified, so I reverse my
assessment to the moment the specs will be available.

=>  APD is a good solution inside an organization but is a bit heavy
for the poor guy at home.

=> this is not a secret I am in favor of RA extension for the simple
case. It was with APD the favourite solutions at the interim meeting
but RA lacked a document (now this is fixed, thanks to Nathan Lutchansky).
I believe with some work we can get something nice and very easy to
implement (the last point is critical: we are already very late).

=> I agree about DHCP: as the dynamic address allocation doesn't make
sens for IPv6, DHCPv6 has to be heavily changed (simplified!) before
to become a reasonable option.

Thanks

[email-masked]

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Fri, 22 Mar 2002 11:10:33 +0900

> - router renumbering hasn't been made to work yet, so I doubt that's a

I agree. Moreover, you can't use it when you assume a site-boundary between
a WAN port and LAN ports of CPE.

> is full statefull DHCPv6).

No. PPPext solves the issue only when you use PPP. That means you need
another solution when you don't use PPP, and that makes it difficult to
achieve zero-configuration enviroment.

> - dhcpv6 will work ok, I think, but is a bit complex for being usable

Yes, that's why Ralf proposed the DHCP subset or DHCP-lite named "DNCP".

> - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return

I think APD is simple enough, and DNCP is also simple enough. Technically
there is almost no difference between DNCP and APD.

> - RA (Lutchansky) is a nice hack, kinda works with hacking.

It assumes only P-to-P enviroment. Again you need another solution for
non-P-to-P enviroment. Our goal is to achieve auto-configuration, right?
Then, how dose a CPE know whether it is conneted to P-to-P link or P-to-MP
link automatically?

> implement full DHCP, or even the minimal set of "stateful" DHCP.

Both APD and DNCP are "stateful".

I'm providing commercial IPv6 services today, and will start IPv6 over
DSL/FTTH services soon. You should understand that "stateful" is one of the
most important requirements of commercial ISPs.

How do you charge and/or solve abuse problems while you don't know who used
which prefixes and when?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Mar 2002 04:23:44 +0200 (EET)

> achieve zero-configuration enviroment.

Which is why I said 'PPP connections'. :-)

> Yes, that's why Ralf proposed the DHCP subset or DHCP-lite named "DNCP".

Which may still be too heavy.

> there is almost no difference between DNCP and APD.

True, but APD has IMO unnecessary components of stateful nature, like 
prefix return message.

> Then, how dose a CPE know whether it is conneted to P-to-P link or P-to-MP

Prefix Delegation need not be (IMO) completely automatic: it's completely
ok to have to add a 'request-prefix interface eth0', 'request-prefix
interface any', or whatever in the configuration of the CPE.

Via that, detecting the link type is irrelevant: we don't necessary end up 
with one mechanism already.

> Both APD and DNCP are "stateful".

see below.

> How do you charge and/or solve abuse problems while you don't know who used

I don't think that anyone is assuming 100% automatic prefix generation 
like EUI64 IID generation: rather, I assume that in (at least almost) 
every case, the prefixes will be configured statically somewhere, along 
the lines "identifier/customer: prefix".

With stateful above I meant protocols which expect one to request a prefix 
and return it back, release it, return it back if no longer used, etc. -- 
consider router advertisements which aren't stateful in that manner.

But these are what the requirements document is for..

---

From: Tim Chown <[email-masked]>
Date: Fri, 22 Mar 2002 02:34:27 +0000 (GMT)

> the lines "identifier/customer: prefix".

Which is what DHCP(v6) is good at, and it may not be overkill if you also 
want to run a v6 only network and also use DHCPv6 as your DSTM server, for
example.

> consider router advertisements which aren't stateful in that manner.

I think in many situations you'd expect a static prefix, but there may
also be situations where any prefix is OK and so a static dhcpv6 mapping is
not necessary.  This might be useful in the MONET area to get a temporay
prefix for a mobile network, so we shouldn't perhaps constrain thinking to
fixed CPE?

tim

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Mar 2002 04:40:35 +0200 (EET)

> want to run a v6 only network and also use DHCPv6 as your DSTM server, for

I'll omit my comments about the marriage of DHCPv6 and DSTM from this 
forum :-).

> prefix for a mobile network, so we shouldn't perhaps constrain thinking to

"non-stateful" manner does not necessary discount these: just advertise
the prefix with e.g. lifetime of 60 seconds.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 21 Mar 2002 21:30:07 -0800

Hello Yamasaki,

Only one comment...

> How do you charge and/or solve abuse problems while you don't know who used

Maybe what's needed is to have the default router report stateless
transitions by way of MIB, explicit signaling, ...  The right time to
do this would be when a stateless autoconfigured host gets a new
entry in the router's neighbor cache.

This only gives you when, along with the MAC address of who.

Maybe AAAv6 would give you who -- but it's not on the standards
track :-(   but it's easier than DHCPv6...

Regards,
Charlie P.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 22 Mar 2002 07:53:39 -0500

Hi Pekka,
     Just one comment

> - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return

As one of the authors of APD, I can concretely say that some of the
messages used in -02 can be removed.  If I recall, the Prefix Return
message was added based on someone's suggestion.  My original thinking
was that the lifetime of the prefix would be used to determine when
it was no longer valid.

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Mar 2002 23:01:07 +0200 (EET)

On Mon, 25 Mar 2002, Yamasaki Toshi wrote:
> Probably what I want to say is that it'd the best idea to have one
> "lite-weight" solution to solve major requirements, which is compatible
> for a "full-covered" solution to solve also minor requiremnts. To
> achieve this, there seems three solutions:
> 
> 1) DNCP (DHCP-lite) as a "lite-weight", DHCP as a "full-covered"
> 2) APD as a "lite-weight", APD-heavy  as a "full-covered"
> 3) RA+PDopt as a "lite-weight", RA+PDopt-heavy as a "full covered"
> 
> Ralf is writing DNCP, and currently nobody seems writing APD-heavy nor
> RA+PDopt-heavy.

I don't think mechanisms of 2) or 3) (ie. ICMP6) even should be used for 
"heavy" operations: if one requires these, one can always use DHCPv6 or 
static allocations.

So, the only problems I see outright:

 1. writing requirements to see what we actually want
 2. developing APD further, e.g. to a bit more lightweight solution
 3. writing a lightweight DHCPv6 solution; IMO, DHCPv6 specification 
should be split anyway though.
( 4. possibly fixing the few problems with RA delegation, if that is 
preferred to APD)

> Now I see what you mean by "statefull" :-)
> I agree with you that you don't need "prefix return" like messages when you
> assume only dedicated(fixed) prefix and flat rate access services, and I
> guess that is often the case.

True.  And this can be, to some extent, be remedied by short lifetimes and 
need be.

> But if you assume also non-dedicated(dynamic?) prefix and non-flat rate(per
> time?) access services, for exapmle, remote access or roaming services, your
> customers probably want "prefix return" like messages, for exapmle when they
> want to temporalily stop using IPv6 access to save mony but continue to use
> IPv4 access.
> 
> # I don't like this kind of services personally :-), but we should avoid
> killing any posibility of new business models.

Solutions don't have to cover every corner case.  This is IMO one where 
DHCPv6 could be useful, due to its stateful nature.

> I agree with you that Prefix Delegation doesn't have to be 100% automatic.
> 
> But I still don't think that it is a better idea to define different
> mechanisms for P-to-P and non-P-to-P respectively, because,  for example, it
> is difficlt for a CPE to know whether its eth0 is connceted to P-to-P
> ethernet or non-P-to-P ethernet.

In non-P-t-P case the security is important (assuming that multiple 
customers share one ethernet medium); the other case might be more than 
one ISP in one non-P-t-P medium but with only one customer.

In both cases, security associations (e.g. manually keyed ones) could be 
built which would protect (mostly at least) from unwanted queries and 
responses.  If not via IPSEC, the packets would have to contain some form 
of identification other than addresses anyway.

In the first case, instead of all-routers multicast address,. some other,
e.g.  "all-delegators" could be used.

In the second case, I imagine one would like to use DHCPv6 for policy 
reasons.

Some other issues in non-P-t-P cases could be fixed as well I think; only, 
I think we'd first have to identify which links are non-P-t-P so we can 
decide whether this restriction is an important enough one to be required 
for consideration.

Routed ATM?
Bridged ATM?
Dial-up?
Cable?
Some Ethernet solutions (which?)
...

Potentially, I see only Bridged ATM except some weirder Ethernet ones
(e.g. Ethernet to a neighbourhood with one upstream router and all homes
there connected to a switch) as possibly problemaic here, but I don't have
that deep knowledge on how all of these are used in the world to say for 
sure.

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Mon, 25 Mar 2002 01:32:08 +0900

Probably what I want to say is that it'd the best idea to have one
"lite-weight" solution to solve major requirements, which is compatible for
a "full-covered" solution to solve also minor requiremnts. To achieve this,
there seems three solutions:

> Which is why I said 'PPP connections'. :-)

OK, I see :-)

---Toshi Yamasaki / NTT Communications