Subject: RE: PPP and Global Addresses

From: NOISETTE Yoann FTRD/DMI/CAE <[email-masked]>
Date: Fri, 15 Feb 2002 11:55:12 +0100

The draft-haberman-ipngwg-auto-prefix-01.txt says :

"4.4 Prefix Delegation 
    
   After the request is verified to be acceptable, the Delegating 
   Router allocates the requested prefix size from its pool of 
   available addresses. The creation and management of that pool is 
   beyond the scope of this document, but it can be supposed that 
   minimalistically a Delegating Router will be statically configured 
   with a fixed pool."

What I meant is that the pool used by the Delegating router, in which it
takes the prefix it delegates to Requesting routers, could be set using the
DHCPv6 option for prefix delegation. Actually, only static (I understand
"manual") configuration is considered.
For instance, when a Delegating router is asked for a prefix, and can't
answer because it doesn't have enough resources any more, it could then rely
on the DHCPv6 option to get another pool... and then proceed to the required
Prefix Delegation. 

Sorry this was not clear, hope it is now ;-)

Yoann

-----Message d'origine-----
De : Yamasaki Toshi [mailto:[email-masked]]
Envoyé : vendredi 15 février 2002 11:44
À : NOISETTE Yoann FTRD/DMI/CAE; Lilian Fernandes;
[email-masked]
Cc : [email-masked]
Objet : Re: PPP and Global Addresses

> "PD (Automatic Prefix Delegation)" doesn't specify any means to set the
> prefix pool the routers rely on for delegation, apart from a manual
setting.

Could you kindly explain what you mean by this sentence in another way? I
did't get the point...

> The DHCPv6 option could be used in this aim, and would be therefore
> complementary to PD...
> Moreover PD also deals with routing protocol negocation, and does then
more
> than just prefix delegation... This point is interesting in so far as the
> reachability of the subnet(s) corresponding to the delegated prefix must
be
> achieved in a way or another...

I believe PD and DHCP are not competing, but can live together, like RA and
DHCP can do so at a subnet.

My understanding is that PD is "third-party-serverless autoconfig" or
"third-party-server independent autoconfig" and DHCP is "third-party-server
dependent", because PD is for routers which actually delegate and route the
delegated prefix, and DHCP is not necessarily so.

>
> Yoann
>
> -----Message d'origine-----
> De : Yamasaki Toshi [mailto:[email-masked]]
> Envoye : jeudi 14 fevrier 2002 04:52
> A : Lilian Fernandes; [email-masked]
> Cc : [email-masked]
> Objet : Re: PPP and Global Addresses
>
>
>
> "PD (Automatic Prefix Delegation)" is one of the choices.
>
> draft-haberman-ipngwg-auto-prefix-01.txt
>
http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-01.
> txt
>
> To solve all the configuration issues with DHCPv6 might be another good
> choice, but I guess PD be a minimum requirement for those who want an
> automatic prefix delegation mechanism for (for example) IPv6 access
> services,  and DHCPv6 would be an option for those who want more.
>
> ---Toshi Yamasaki / NTT Communications
>
> > Hi,
> >
> > I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks
> > about the negotiation of the Interface-Identifier and specifies the
> > Interface-Identifier Configuration Option. In this case the upper 64
bits
> > are just fe80::
> >
> > It does not mention if there is any standard way to configure a
> > global/site-local prefix on a point-to-point link i.e. are there
> > configuration options to let one side tell the other about a global
> > prefix?
> >
> > Or is it just left upto the users at both ends to decide on a prefix
> > somehow and then configure it on each end?
> >
> > I'm sorry if there is an RFC about this that I missed...
> >
> > Thanks,
> > Lilian
> >
> > _____________________________________________________________________
> >
> > Lilian Fernandes
> > AIX TCP/IP Development - IBM Austin
> > Tel: 512-838-7966 Fax: 512-838-3509
> >
> >
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> >
> >
>
> --------------------------------------------------------------------
> 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, 15 Feb 2002 16:55:25 +0100

In your previous mail you wrote:

      "... The creation and management of that pool is
      beyond the scope of this document, but it can be supposed that
      minimalistically a Delegating Router will be statically configured
      with a fixed pool."

=> this notion of static (DHCP terminology) / manual (common terminology)
allocation is more important than one can believe. The difference between
BOOTP and DHCP is the introduction of the dynamic (DHCP terminology)
allocation. My main concern about DHCPv6 is the dynamic allocation
makes sense only for a scarce resource: this is the case for IPv4
addresses but definitively *not* for IPv6 addresses... So DHCPv6 is
basically useless (and in the real world not used at all :-).

Regards

[email-masked]

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 15 Feb 2002 08:07:35 -0800

Mr. Dupont, DHCP originally started with allowing dynamic
IP address allocation. A secondary benefit of utility is in
network operations, it is impossible to manually assign IP
address to 100's of hosts let alone 1,000,000's that IPv6
would allow. This about a large network operator, how are they
going to manage their asset of IP address pool - send a person
to manually configure each host, that is silly.

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Francis Dupont
Sent: Friday, February 15, 2002 7:55 AM
To: NOISETTE Yoann FTRD/DMI/CAE
Cc: 'Yamasaki Toshi'; Lilian Fernandes; [email-masked];
[email-masked]
Subject: Re: PPP and Global Addresses

   What I meant is that the pool used by the Delegating router, in which it
   takes the prefix it delegates to Requesting routers, could be set using
the
   DHCPv6 option for prefix delegation. Actually, only static (I understand
   "manual") configuration is considered.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 15 Feb 2002 17:54:36 +0100

=> RFC 2462 "IPv6 Stateless Address Autoconfiguration".

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Fri, 15 Feb 2002 09:00:24 -0800

nope, not enough for a accounting, service termination etc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Francis Dupont
Sent: Friday, February 15, 2002 8:55 AM
To: Dr. Subrata Goswami
Cc: [email-masked]
Subject: Re: PPP and Global Addresses

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Feb 2002 17:51:22 +0000

> basically useless (and in the real world not used at all :-).

I don't think either the ICMP PD or DHCPv6 PD drafts imply that the
prefix lifetimes/leasetimes should be short. the ICMP PD draft makes a
reference to delegating routers having a pool of prefixes to
assign. this is perhaps an unfortunate choice of words.

as it is proposed both DHCP PD and ICMP PD work in the same
manner. both protocols run only on the link between delegating router
and requesting router. there are a couple of ways the delegating
router can use to get the prefix for the user. e.g from an AAA record,
manually configured on the delegation router, from a DHCP server or
from a locally configured pool.

apart from a locally configured pool, where you lack stable storage,
none of these imply "dynamic" allocation. both ICMP PD and DHCP PD
_can_ be used for dynamic allocation but that is an operational
choice.

would you be happier if we renamed it to SNCP (Simple Node
Configuration Protocol)? :-)

for me this boils down to picking a packet format on the wire. DHCP
offers a more flexible option format, is more extensible, has a
defined relay mechanism, offers a Reconfigure mechanism so it is
possible to poke the requesting router.  I have no problem with using
ICMP PD, my point is that as we move along it is going to look awfully
much like DHCP.

cheers,
Ole

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 15 Feb 2002 10:32:01 -0800

Ole Troan wrote:
> ...

Actually, yes. Routers are not hosts, so configuring routers with what
is titled a host specific protocol will create more confusion than it is
worth.

> ICMP PD, my point is that as we move along it is going to look awfully

If we are going to need a stateful protocol tied to an authentication
system, using the wire format and option richness of a widely deployed
protocol makes more sense than inventing a new one. At the same time,
going that route requires a serious look at the defined options to find
any potential security holes that may exist because there was a
historical assumption that the option applied to an end system not a
router. If a router requesting one of the existing options opens a big
hole, we really do need a new protocol.

Tony

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 12:21:42 +0100

=> I know this argument but management is not allocation.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Sat, 16 Feb 2002 17:50:18 +0200 (EET)

> is titled a host specific protocol will create more confusion than it is

Just a point: the value of router/host toggle is interface-specific.  This 
was dicussed, hmm, probably around 6-9 months ago here in the context of 
RFC2461.

I also think DHCP and what not should not be used for router 
configuration.

-- 
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

---

From: Ralph Droms <[email-masked]>
Date: Sun, 17 Feb 2002 13:53:55 -0500 (EST)

I have to ask - because I've never heard it raised as an issue outside
this mailing list - has anyone ever heard a *network administrator* or
other customer of IETF protocols say that "configuring routers with what
is titled a host specific protocol will create more confusion than it
is worth."

If the name is truly a problem, I'm happy to follow up on the suggestion
that we rename DHCP to "Dynamic Node Configuration Protocol" or "Dynamic
Site Configuration Protocol" or "Yet Another Configuration Protocol".  I'm
having a hard time believing we're making technical decisions about
protocol design based on the *name* of the protocols involved.

Sheesh.

BTW, just to review some ancient history, I added the infamous sentence
"DHCP is not intended for use in configuring routers." (originally in
RFC1531 and carried forward to RFC1541 and RFC2131) to limit the scope of
the problem we were trying to solve.  That was (literally) 10 years ago.
Maybe it's OK now to reconsider that constraint.

The sentence is *not* included in draft-ietf-dhc-dhcpv6-23.txt.

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Mon, 18 Feb 2002 14:11:59 +0700

[I changed the Subject line...]

    Date:        Sat, 16 Feb 2002 17:50:18 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | I also think DHCP and what not should not be used for router 
  | configuration.

I'm trying to understand what is lurking in the background here, and
I think I'm failing.   That is, I have no idea at all what the objections
are, the oft repeated "I don't think ... should be used" (I picked just
one example above) means nothing - there's no explanation for what the
problem might be.

It could just be that people believe that the only way to ever configure
a router is manually, and that any protocol to automate the process is
necessarily flawed.   If so, I'd like to understand why, but I think I'd
tend to ignore that sentiment - other than to make sure that implementations
keep on making it possible to manually configure, so that people who
believe this don't have the rug yanked out from under them (and in certain
particular circumstances, I think this probably includes all of us).

Or, it could be that there's something in particular about DHCP that makes
it unsuitable - its lack of authentication for example (is that still true
of DHCPv6?  One day I must go read that draft...) - or that if you're going
to have to configure authentication manually, you may as well just config
the addresses (etc) instead.

So, could all those objecting please say exactly what it is that is the
problem, and not just repeat the "I don't like it" comments?

Then perhaps it will be possible for others to refute the alleged problems,
or to learn about a defect they weren't aware of, and fix the protocol (or
even invent a new protocol, if the existing possibilities are beyond fixing).

I find it a bit difficult to believe though that there's anything so
special about a router that makes it impossible to configure using a
protocol ... after all, we have (most of us) been using TELNET to configure
routers for many many years now, and while there's usually a human on the
client end of the telnet connection, there doesn't need to be - a script can
configure routers just as easily (and I've seen scripts around for this kind
of purpose).

These days routers even offer http servers as a config device, and automation
to talk to http servers is as comon as dirt.   And then, there are also routers
that simply invent their own configuration if they can figure out some data
somehow.

So, it is pretty clear there's a demand for configuring routers some way other
than manually, it is also pretty clear that it is possible.   If it can be done
and people want it, it sounds to me as if a standardised method (as an 
optional extra, not as the only way) is likely to be an improvement.

kre

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 Feb 2002 17:26:46 -0800

KRE,

>particular circumstances, I think this probably includes all of us).

It's a good question.  My suspicion is that because much of many routers 
configuration is specific each router, that it doesn't matter to much if it 
is entered directly into the router with a CLI or web interface, or 
equivalently typed into some sort of protocol server.  Also much of a 
routers configuration is not amenable to dynamic creation.  Unlike hosts 
there isn't too much labor saving in having a DRCP.  Where a protocol might 
be needed, people have gotten around the lack of a protocol by creating CLI 
files with an editor and pushing them to the router.  The editor makes it 
easy to make the common parts the same and customize the rest.  I think 
there can even be includes in many vendors CLI files.

There are cases (e.g., sub routers at the end of DSL, etc.) where the 
configurations are very similar, where some sort of DRCP might be 
useful.  I think DHCPv4 is used for this today when the stub router also 
includes a NAT.

Bob

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Feb 2002 17:40:52 -0800

there are isps where a human never types at a router (except to debug) and
all configuration is programatically generated from enterprise and customer
data entered by folk from sales to provisioning to address admin through
sexy gui interfaces.  the canonic configuration is the data in the data-
base, and the classic phrase "the network is the data-base of record" is
anathema.

these configuration generation systems have 'back ends' (excuse the compiler
term) for many vendors' so-called configuration languages, and the router
brand, model, and sw version are but more parameters in the data-base.

randy

---

From: Ole Troan <[email-masked]>
Date: Wed, 20 Feb 2002 01:52:46 +0000

> brand, model, and sw version are but more parameters in the data-base.

that doesn't cross administrative boundaries very well, and doesn't
help a provider to assign prefixes to its customers. kudos for the
system though. :)

/ot

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Feb 2002 18:00:49 -0800

> that doesn't cross administrative boundaries very well

crosses some, not others

> and doesn't help a provider to assign prefixes to its customers

it can.  that would rely on
  o the system tracking what is allocated to the pop and aggregation
    router pool
  o sales/provisioning being able to specify how much the customer
    needs

of course, in v6, this will all be easier, as space is infinite, we can
allocate infinite space to each customer :-)

folk don't really think the survivors will be still scrabbling at the
coal face with their bare fingernails in five years, do they?  it just
does not scale.  isps which do not scale get bought by telephants who
do not think, and they make great bed-fellows.

randy

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Feb 2002 11:33:27 +0200 (EET)

> particular circumstances, I think this probably includes all of us).

In my opinion, DHCP was not designed, from the start, to configure 
routers.  Now, as an afterthough, capabilities are added to do just that.  
My worry is that some of the basic assumptions of DHCP architecture do not 
necessarily fit well into the new requirements of configuring routers.

From an operational point-of-view, I would not like have automatic
configuration mechanisms (apart from, possibly, NTP/DNS/... settings) for
the important routers.

However, to make renumbering even remotely possible, I don't see a
problem, as such, with configuring very simple routers (don't run routing
protocols at all, no access-lists or acl's dynamically created, etc.) like
DSL/Cable boxes via some mechanism.  I think that would only be sensible.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 20 Feb 2002 07:49:52 -0800

Randy,

>base, and the classic phrase "the network is the data-base of record" is

Interesting.  Does this apply to both edge routers near the customer and 
the backbone-peering routers?  Are these tools commercial products or are 
they developed by each isp?

>brand, model, and sw version are but more parameters in the data-base.

To bring this back to the thread, do you think there is a need for a 
protocol here or are the current solutions adequate?  It must be fun to 
keep these tools in sync with sw releases, differences in vendor 
capabilities, etc.

Bob

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Feb 2002 08:02:50 -0800

> they developed by each isp?

one i know goes all the way to cpe.  none are commercial, too small a
market, too few large isps. so all commercial efforts i know failed.

note that there are embarrassingly few of these systems.  many isps do
configure by hand, and some embarrassingly large ones.  as the consequence
of manual configuration is horrible cost/customer curves as things scale
up, those that don't will die in the margin squeeze just as they're dying
in long distance minutes today.  sometimes, the goddess is just.

> keep these tools in sync with sw releases, differences in vendor 

job security for old hackers!  :-)

i suspect/hope that 20 years from now we will understand a lot more about
infrastructure topology discovery and construction, accompanied by solid
underlying theory, and will view this discussion as pretty primitive.  of
course, we have to live in today.  but we should refrain from being cute
or complex.

randy

---

From: Bob Hinden <[email-masked]>
Date: Wed, 20 Feb 2002 08:25:01 -0800

Randy,

>course, we have to live in today.  but we should refrain from being cute

I hope in 20 years we will understand a lot more about many things :-)

Bob

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Feb 2002 08:43:13 -0800

> You answered all the questions in Bob's note except this one.
> And it is the most important one. :)
>>> protocol here or are the current solutions adequate?

no.  i answered it.  essentially, it may be worthwhile, but under no
circumstances should it be cute or complex.

randy

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Thu, 21 Feb 2002 01:51:29 +0900

Ah, now I understand what you mean. Excuse my slow brain :-)

In my scenario for Dial-up or DSL access services, some kind of L2
authentication, CHAP or 802.1x for example, runs before
AutomaticPrefixDelegation, and the delegating router gets a prefix from
Authentication server, Radius for example.

----- Original Message -----
From: "NOISETTE Yoann FTRD/DMI/CAE" <[email-masked]>
To: "'Yamasaki Toshi'" <[email-masked]>; "NOISETTE Yoann FTRD/DMI/CAE"
<[email-masked]>; "Lilian Fernandes"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 15, 2002 7:55 PM
Subject: RE: PPP and Global Addresses

"4.4 Prefix Delegation

Yoann

-----Message d'origine-----
De : Yamasaki Toshi [mailto:[email-masked]]
Envoyé : vendredi 15 février 2002 11:44
À : NOISETTE Yoann FTRD/DMI/CAE; Lilian Fernandes;
[email-masked]
Cc : [email-masked]

setting.

more
be

bits