Subject: RE: PPP and Global Addresses

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 10:55:56 -0500

Francis,

Catching up on old mail I saved for DHCPv6.  Let me just start with your
view is wrong.
I don't see the point of arguing with you.  DHCPv6 will be deployed and
widely used.  So will stateless.  Its not an IETF discussion worth
having in this vein IMO.  You have your opinion and thats fine.  Many of
us who also have implemented IPv6, talking to customers, and working
with the market think you are 100% wrong.  They want DHCPv6.

/jim

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 11:55 AM
> To: Dr. Subrata Goswami
> Cc: [email-masked]
> Subject: Re: PPP and Global Addresses 
> 
> 
>  In your previous mail you wrote:
> 
>    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.
>    
> => RFC 2462 "IPv6 Stateless Address Autoconfiguration".
> 
> [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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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, 07 Mar 2002 14:29:53 +0100

=> do you argue we need dynamic address allocation for IPv6?

   widely used.

=> Jim, you already said that 5 years ago. I tried to believe in DHCPv6
but this is too hard, after years of discussion we still have no
published specs!

   Its not an IETF discussion worth having in this vein IMO.

=> a document in the standard track should have to prove its utility,
so this is still a valid IETF discussion topic.

   Many of us who also have implemented IPv6, talking to customers,
   and working with the market think you are 100% wrong.

=> near all IPv6 implementors are against DHCPv6 or are indifferent.
You are the only notable exception.

   They want DHCPv6.
   
=> they believe they need it because they have not yet understood
the differences between IPv6 and IPv4, or with other words, that
allocation and management are not the same thing.

Regards

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Mar 2002 08:44:28 -0500

Francis,

I have to jump in here - DHCPv6 is *not* just for dynamic address 
allocation. Have those who are claiming that DHCPv6 will not be used 
actually read the spec?  It will be used for other configuration 
parameters, as described in draft-droms-dnsconfig-dhcpv6-01.txt  Arguments 
that DHCPv6 has no utility because of stateless address autoconfiguration 
are bogus.

Once again, stateless address autoconfiguration is great.  But it's not 
enough.  An IPv6 host needs *at least* DNS configuration information to be 
useful.  DHCPv6 is a reasonable way to provide that additional 
configuration information.

Is there a buzz from network designers, managers or admins - folks who 
actually *run* networks and who understand IPv6 - asking for DHCP to go away?

- Ralph

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Mar 2002 17:52:03 +0100

actually read the spec?

=> I read the spec (one of the statements I used in a message to Jim
is from the introduction of the draft). My concern is the primary
objective of DHCPv6 is the dynamic address allocation, and a protocol
which can fulfill all other functions should be far simpler.

   It will be used for other configuration 
   parameters, as described in draft-droms-dnsconfig-dhcpv6-01.txt  Arguments 
   that DHCPv6 has no utility because of stateless address autoconfiguration 
   are bogus.
   
=> the issue of DNS configuration is solved by another protocol.
You can disagree with the DT conclusions (or the principle of DTs)
but they propose a dedicated simpler protocol. DHCPv6 has to drag
the dynamic address allocation ball & chain and shall ever be far
more complex than any other solution for "additional configuration".

   useful.

=> this is why a design team had to look for a solution.

   DHCPv6 is a reasonable way to provide that additional 
   configuration information.
   
=> I strongly disagree and it seems my opinion is shared by many
persons in the IPv6 WG (at the exception of Jim).

   Is there a buzz from network designers, managers or admins - folks who 
   actually *run* networks and who understand IPv6 - asking for DHCP to
   go away?
   
=> we don't ask for DHCPv6 to go away. DHCPv6 is simply not here
and for the addressing point of view stateless autoconfiguration
proved it was enough.

Regards

PS: I worked many years on DHCPv6 so I believe I won the right
to express my opinion: I was tired to try to save DHCPv6 (to find
another usage/utility) for instance so now I've given up.
BTW at the interim meeting I was the only person who tried to make
DHCPv6 an option for prefix delegation (it was my last attempt)
and *nobody* voted in favor of it.
(cf http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.txt)
--------------------------------------------------------------------
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: Ralph Droms <[email-masked]>
Date: Thu, 07 Mar 2002 12:26:09 -0500

At 05:52 PM 3/7/2002 +0100, Francis Dupont wrote:
>    parameters, as described in 
> draft-droms-dnsconfig-dhcpv6-01.txt  Arguments

I do disagree with the DT conclusion - as do other WG member
who spoke up in SLC - but I'll let the rest of the
WG members make up their own minds about the various protocol
proposals.

If the other solutions are so simple, why aren't they done yet?

- Ralph

---

From: Rob Austein <[email-masked]>
Date: Thu, 07 Mar 2002 14:28:40 -0500

[Replies intentionally redirected to mailing list by author -- I get
 way too much mail and really don't need duplicate copies from a list
 that generates as much traffic as this one.  Thanks.]

> WG members make up their own minds about the various protocol

I agree with Ralph and disagree with the design team conclusion, for
several reasons:

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.

2) While I applaud the ingenuity and enthusiasm of all the people who
   have come up with interesting ways to configure things in the IPv6
   universe without using DHCP, I have yet to see any proposals as
   simple as just using boring old DHCP for most of this stuff.  We
   have a pretty good understanding of how DHCP works and what's
   required to support it (for some definition of "we" that may or may
   not include the members of this WG, a subject on which I decline to
   have a public opinion).  Some of the proposals to replace DHCP, on
   the other hand, are pretty far out on either the research or kludge
   axes.  While I am not in principle opposed to cool new stuff, I
   don't think it's sound engineering to do new stuff just for the
   sake of being different.

3) As I stated in my rant at the IESG plenary in Salt Lake, I think
   that the IPv6 WG has real work to do, and redesigning the entire
   Internet from the ground up isn't it.  DHCP will do this job well
   enough, 'nuff said, can we please move on now?

Since Ralph is much politer about this than I usually manage to be, I
will now slink back under my rock.

--Rob

---

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

>    crashing).  Ralph, please correct me if I'm wrong about this.

Rob - yes, DHCP clients and servers that don't do address assignment
can be implemented to discard other messages and options that are not
of interest.  For DNS configuration, clients and server would only
need to implement the Information-Request and Reply messages, which
are used in a two message exchange.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 13 Mar 2002 23:00:03 +0900

(We should probably change the subject...)

>>>>> On Thu, 07 Mar 2002 14:28:40 -0500, 
>>>>> Rob Austein <[email-masked]> said:

>    don't think it's sound engineering to do new stuff just for the

Could you be more specific about the "new stuff", please?  I agree
that the "level 2 compliance" described in
draft-ietf-ipv6-dns-discovery-04 can be called a "new stuff", but the
level 1 compliance, which is now the only main part of the draft,
needs almost nothing new.  In particular, if we use unicast well-known
addresses with the level 1 compliance (this will work in a small
network such as a home network or a SO-HO office), we do not need new
implementation.  It's just a matter of configuration.

I admit that DHCPv6 only with information resources is also simple.
However, in order to apply DHCPv6 in the real network, we'll need

- a DHCPv6 relay agent (basically) in every subnet, or
- multicast routing when we use a well-known multicast addresses for
  DHCP servers

I believe both of two can be a problem to deploy DHCPv6 which is not
easy to deal with.  That's one of the key reasons why the design team
preferred the current approach to DHCPv6.  (correct me if I'm wrong >
other team members.)

					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: Rob Austein <[email-masked]>
Date: Wed, 13 Mar 2002 13:23:39 -0500

The level 1 compliance stuff is only simple in the case of a single
subnet.  As soon as you have routers between the client and the
server, you have to do something to get the packets across the router.
I suppose we could have a discussion about whether magic unicast
addresses (which are really a limited special case of anycast) are
better or worse than multicast, but I doubt that such a discussion
would change any minds.

The place where I do see a real difference is that
draft-ietf-ipv6-dns-discovery-04 tacks new functions (service
discovery and configuration) onto DNS.  DNS was not really designed
for this, and while it's certainly possible (RFC-1925 2.(3)) I think
it's better to use a protocol that was designed for these tasks,
particularly if by doing so one also builds an infrastructure that
makes it easier to solve other problems (eg, configuring NTP).
--------------------------------------------------------------------
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: Thu, 14 Mar 2002 10:48:57 +0900

>>>>> On Wed, 13 Mar 2002 13:23:39 -0500, 
>>>>> Rob Austein <[email-masked]> said:

> server, you have to do something to get the packets across the router.

Correct, and the "something" is to advertise the corresponding host
route(s) in the site's routing system.  I'm actually living with this
configuration.

> better or worse than multicast, but I doubt that such a discussion

You're probably right, if we want to decide which is "better".
However, I'm quite sure that the unicast/anycast approach is easier to
deploy than the multicast one (whose scope is larger than link-local).
(Again) the unicast/anycast approach has already run in my environment
using a commercial routers.  On the other hand, I don't know router
products that officially supports IPv6 multicast routing.

> discovery and configuration) onto DNS.

If you're talking about the level 2 compliance, I agree with you.  The
level 1 compliance does not need any new functions in DNS.

> DNS was not really designed

I agree here (thus I'm not so enthusiastic about the level 2
compliance.)

					JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Sun, 17 Mar 2002 09:41:01 -0500

> - a DHCPv6 relay agent (basically) in every subnet, or

Not really a problem, as all routers today have relay agent
support. In DHCPv4, the issue is configuring them. With DHCPv6, they
don't need configuring, they use multicast to find the servers.

> - multicast routing when we use a well-known multicast addresses for

I'd like the WG to think about this point very carefully. In hallway
discussions in SLC, it was asserted to me that the existance of IP
multicast, in home or enterprise networks (as opposed to WANs and
backbones) was not something that IPv6 could depend on. For example, I
was told by one individual that SLP wasn't a viable solution for
service discovery because it relies in multicast. Hence, DNS Discovery
couldn't just use SLP.

The implications of this assertion are very significant.  If site-wide
multicast cannot be assumed, it means basic infrastrcuture protocols
(like DHCP, SLP, etc.), *where* they depend on multicast, won't work,
and we may need to invent protocols (or extensions) that don't have
these shortcomings.

On the other hand, extending an existing protocol or inventing a new
one also has a cost associated with it - perhaps higher than the cost
of getting multicast into a state where it can be relied upon.

So, I'd like to ask the WG:

1) Do people think that the existance of multicast within a site
   (e.g., home, enterprise, etc.) can be assumed?

   Note: I'm assuming link-local multicast will always work, the
   question is whether wider scope (beyond neighboring routers)
   multicast is available.

2) If the answer is "can't assume multicast is present", what should
   be done about it. e.g.,

   - What are the barriers that are preventing multicast from being an
     assumed part of the infrastructure? What is needed to remove
     those barriers?

   - Which infrastructure protocols does IPv6 rely on that assume the
     existance of multicast, and how are they limited if multicast is
     not available?

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Mon, 18 Mar 2002 09:36:09 -0800

Thomas,

>    question is whether wider scope (beyond neighboring routers)

As much as I would like to see it otherwise, except for link (and maybe 
subnet) scoped multicast, I don't think we can assume multicast across a 
wider scope.  I suspect it will be more the exception than the norm.

>      assumed part of the infrastructure? What is needed to remove

Don't we have a whole working group dealing with this (e.g., mboned)?

It's a complicated mixture of routing protocol scaling, lack of agreement 
of inter-domain routing protocols, lack of interoperability between vendors 
of multicast routing protocols, few compelling applications that need 
multicast that can't be meet with unicast, etc.  There are a few places 
where it is used (i.e., financial industry), but as far as I can tell it's 
not widely adopted much beyond that.

>      existance of multicast, and how are they limited if multicast is

Off the top of my head, DHCPv6 and Router Renumbering.

Bob

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Mar 2002 19:36:34 +0700

Date:        Mon, 18 Mar 2002 09:36:09 -0800
    From:        Bob Hinden <[email-masked]>
    Message-ID:  <[email-masked]>

  | As much as I would like to see it otherwise, except for link (and maybe 
  | subnet) scoped multicast, I don't think we can assume multicast across a 
  | wider scope.  I suspect it will be more the exception than the norm.

When I saw Thomas' question, I thought that too.

In the intervening few days however, I happened to get asked by people
back home why the "ghost" program (that does something or other with PCs)
wasn't working through our routers - it worked fine with client & server
on the same cable, but not otherwise.

They suspected broadcast packets not being "helped" - I asked for a
packet trace (I'm not there at the minute) and what appears is IP multicast.

So, on my net more than link wide multicast didn't exist last week,
and does exist this week...

Of course, this is IPv4, not IPv6 - but I think it demonstrates the
point.   That is, that all it is going to take is for there to be an
application that actually needs multicast, and multicast will appear
(at least within the site scope, perhaps even more than that).

It would be a mistake to start counting nets with multicast currently
enabled (or where if you ask the admin they'd say "sure, I can enable
that") and from the low number of responses, start avoiding requiring
multicast for new protocols.   Just require it, that itself will be
enough to get it implemented & deployed.

kre