Subject: RE: PPP and Global Addresses

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 11:03:15 -0500

we can deploy DHCPv6 very quickly to provide prefixes.  that will be the
deciding factor but will the spec work?  thats our job here.  If you
don't want to work on it don't.

/jim

> -----Original Message-----
> From: Nathan Lutchansky [mailto:[email-masked]]
> Sent: Saturday, February 16, 2002 12:25 PM
> To: [email-masked]
> Subject: Re: PPP and Global Addresses
> 
> 
> IMO, there are two separate scenarios in which some sort of prefix 
> delegation needs to be used:
> 
> 1) A router establishes a point-to-point connection to a provider.
> 2) A new router is connected to a site's backbone link.
> 
> From Brian Haberman's comments at the interim meeting, it 
> seemed that APD 
> was designed for scenario (2), providing a means to "grow a 
> network" (his 
> words) without need for manual configuration.
> 
> However, scenario (1) seems much more common, and indeed was 
> the origin of 
> this thread.  Small IPv6 sites are inevitably connected to 
> the 6bone with 
> either a p-t-p tunnel or PPP, and there is no good reason we 
> shouldn't 
> have some kind of mechanism to autoconfigure the border 
> routers at these 
> sites.  A draft by Itojun 
> (draft-itojun-ipv6-dialup-requirement-02.txt) 
> describes some of the mechanisms that could be used for 
> configuration, but 
> makes no recommendations.
> 
> Instead of using a stateful protocol like DHCPv6 or APD to configure
> customer sites, perhaps it would be best to use router 
> advertisements on
> the p-t-p link.  This was one of the more popular candidates 
> for dialup
> configuration during Itojun's presentation in Seattle (the 
> other popular
> candidate was APD).  Instead of overloading the Prefix 
> Information option,
> however, we could add an additional option to the router advertisement
> messages, "Delegated Prefix".  This option could only be used on p-t-p
> links, of course.
> 
> This technique would be lightweight, would be easy to 
> implement for both
> the ISP and client sides, and would provide all the 
> functionality needed
> for 90% of sites.  -Nathan
> 
> -- 
> +-------------------+---------------------+------------------------+
> | Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
> +------------------------------------------------------------------+
> |  I dread success.  To have succeeded is to have finished one's   |
> |  business on earth...  I like a state of continual becoming,     |
> |  with a goal in front and not behind. - George Bernard Shaw      |
> +------------------------------------------------------------------+
> 
--------------------------------------------------------------------
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: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 11:04:48 -0500

Ralph,

It was brilliant to re-discover what dhcp can do for IPv6.  This will
also work with router renumbering very well in the real market.

/jim

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Sunday, February 17, 2002 1:54 PM
> Subject: RE: PPP and Global Addresses
> 
> 
> 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
> 
> On Sat, 16 Feb 2002, Pekka Savola wrote:
> 
> > On Fri, 15 Feb 2002, Tony Hain wrote:
> > > Ole Troan wrote:
> > > > ...
> > > > would you be happier if we renamed it to SNCP (Simple Node
> > > > Configuration Protocol)? :-)
> > >
> > > 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.
> >
> > 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.
> >
> >
> > > > 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.
> > >
> > > 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
> > >
> > >
> > >
> > > 
> > 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: "Bound, Jim" <[email-masked]>
Date: Sun, 10 Mar 2002 12:39:23 -0500

just as note for those that don't know dhcpv6 supports multicast too.
/jim

> From: Rob Austein [mailto:[email-masked]]
> Sent: Saturday, March 09, 2002 12:34 PM
> At Sat, 9 Mar 2002 03:27:36 +0100, Hesham Soliman wrote:
> > 
> > I don't have a great knowledge of DHCP but wouldn't this simply
> > message still require a relay agent?
> 
> That's one way to do it.  Another would be clever use of multicast.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 12 Mar 2002 07:50:05 -0500

The DHCPv6 spec defines a well-known site-scoped multicast address
that all DHCP servers listen on.  Assuming a DHCP client has
an address of sufficient scope to which a DHCP server can reply,
the client can send an Information-Request message to that
multicast address to contact a DHCp server without requiring
a relay agent.

- Ralph

At 03:27 AM 3/9/2002 +0100, Hesham Soliman (ERA) wrote:

>   > 1) The portions of DHCP that are required for post-addr-conf (sorry,
>   >    don't have a better name for this) are pretty minimal, and I'm
>   >    pretty sure that one can write conforming DHCP clients
>   > and servers
>   >    that only implement that part of the DHCP spec (more
>   > precisely, the
>   >    only thing that such implementations would have to do with the
>   >    complex part of the spec would be to ignore the messages without
>   >    crashing).  Ralph, please correct me if I'm wrong about this.
>   >
>
>=> I don't have a great knowledge of DHCP but
>wouldn't this simply message still require
>a relay agent?

---

From: NOISETTE Yoann FTRD/DMI/CAE <[email-masked]>
Date: Tue, 12 Mar 2002 14:41:24 +0100

Thanks for the pointer, the slides are very interesting indeed...

I totally agree this is an important topic which should be discussed on this
list. IMO, the three mechanisms have different approaches and assets (for
instance, APD takes routing into consideration, DHCPv6+PD can provide
precious DNS information...), so it is perhaps better, instead of choosing
one mechanism or the other to reach a consensus on what we think is
necessary to provide ISP-to-Customer(PE-to-CPE) prefix delegation leading to
a zeroconfiguration environment as pointed out by Toshi-san.
Moreover, in this aim, both stateful and stateless solutions could be
considered, as pointed out by Jim, and could be discussed as the needs are
indeed not the same. 
To bring a little more to the discussion and lay stress on the fact that
prefix delegation is a important topic, here's another kind of prefix
delegation we can encounter. Though this is  outside this list's work, I
think it is interesting to point that, for instance, RFC 3053 about "IPv6
tunnel broker" provides a way an ISP could use to delegate prefixes to its
IPv4-only-connected clients :

	Quick quote : "Moreover, if the client machine is an IPv6 router
willing to provide
   	connectivity to several IPv6 hosts, the client should be asked also
   	to provide some information about the amount of IPv6 addresses
   	required.  This allows the TB to allocate the client an IPv6 prefix
   	that fits its needs instead of a single IPv6 address."

Yoann

-----Message d'origine-----
De : Yamasaki Toshi [mailto:[email-masked]]
Envoyé : lundi 11 mars 2002 15:05
À : Bound, Jim
Cc : [email-masked]
Objet : Re: PPP and Global Addresses 

Jim and all,

> Differentiate the need for an Intranet vs an Internet.
> Most DHC is deployed on Intranets.  Ralph has responded to you and I
> concur.

I guess we are talking about "what is the best for ISP-to-Customer
(PE-to-CPE) prefix delegation", correct?

Then, there seems three proposals shown below for this purpose. What is your
opinion for each proposed mechanism?

(APD) draft-haberman-ipngwg-auto-prefix-02.txt
(DHCPv6+PD option) draft-troan-dhcpv6-opt-prefix-delegation-00.txt
(RA+PD option) draft-lutchann-ipv6-delegate-option-00.txt

I believe everyone here agrees that zero-configuration environment is very
important for the deployment of IPv6, because we know IPv6 should realize an
world where not only technical people but also much more non-technical
people can enjoy the global address and always-on environment.

To achieve zero-configuration for "ISP-to-Customer (PE-to-CPE) prefix
delegation", we had better have a global consensus about which mechanism is
minimally required for this purpose. Many mechnisms for the same purpose
will make it difficult to achieve zero-configuration enviroment, because CPE
should know which to use before runnning an auto-configuration protocol
among many choices.

My opinion is:

(APD) a good choice for a minimamlly required protocol for prefix delegation
(DHCPv6+PD option) for those who want to more auto-configured parameters
other than site-prefix
(RA+PD option) can be used at only P-to-P enviroment and it is too
restrictive

P.S.

Here is an ppt presentation about the "temporally" conclusion of IPv6
engineers mostly in Japan about this issue.
http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI.ppt
It's a little old because there were no DHCPv6 nor RA proposals for prefix
delegation when we discussed, but comments and opinions are very welcome.

---Toshi Yamasaki / NTT Communications

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 15 Mar 2002 04:50:42 -0500

Toshi-san,

> Jim-san,
> 
> Thank you for your thoughtful opinions and advices. Again, I 
> believe this

thank you for your kind words.

> "ISP-to-Customer site-configuration" is one of the most 
> urgent issues for
> the WG, because no non-technical customers can join to IPv6 
> world unless we
> provide any solution. This positive discussion will help us 
> to solve the
> issue.

Very true and very important we need to make this clear to customers.

> 
> > > Then, there seems three proposals shown below for this
> > > purpose. What is your opinion for each proposed mechanism?
> >
> > OK.  But I want to apply these to real deployment and can't 
> do that on
> first read.  So my responses at this point are an 
> architectural view not an
> implementation view which I will have by the IETF meeting I hope.
> 
> Understand. FYI, some ISPs will (or want to) start IPv6/DSL services
> hopefully in 2002, and we will see some working-in-commercial-services
> implementations soon.

Yes and good point.  Also Hitachi did a talk here about their routers (Madrid IPv6 Summit) and it appears the DSL business is real for sure.  As I said there are some initial dhcpv6 implementations and we have lots of stateless addr conf.

For 2002 I doubt in best case we can get working group consensus till at least the December IETF meeting in 2002 so we will need to do this with vendor products as custom solution for 2002.  But lets not wait to deploy DSL with IPv6.  I can get into this with you offline how one can proceed wearing my implementation hat for prefix delegation.

> 
> > So I can see having two approaches to solve the link or off line
> situations.  But the DHCP6+PD is more robust and can be used in all
> situations.  APD+RA+PD is the lightweight solution.
> 
> I agree with your opinion that APD is the minimally required 
> lightweight
> solution and DHCPv6 is the "FULL-SERVICE" solution.
> It's not clear to me how you think the RA+PD proposal be 
> merged into APD.
> Could you kindly explain the details?

I think Brian Haberman's draft -02 added pieces I thought were missing like lifetimes, and releases.  So maybe that has already taken place.

> 
> > I agree but I believe we can have a stateless and stateful 
> solution for
> different needs.
> 
> Absolutely.

thank you,
/jim

> 
> --- Toshi Yamasaki / NTT Communications
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 15 Mar 2002 04:53:23 -0500

Ole,

> > I agree but I believe we can have a stateless and stateful solution
> > for different needs.
> 
> I think prefix delegation is inherently stateful. both DHCP PD and
> ICMP PD are as such stateful protocols. that is, the delegating party
> has to keep track of which prefixes are assigned where.
> 
> if anyone disagrees, please explain where the statelessness comes into
> the picture.

Good point........

/jim

> /ot