At 09:59 AM 8/25/2003 -0700, Tony Hain wrote:
Ralph Droms wrote:
...
Certainly some of my problems with IPv4LL have resulted, as
you suggest, from the restriction that an interface have just
one dynamic IPv4 address at a time. I think there's more to
the problem - my experience has been
- right?
This would all be fine, but we are hit once again with the question of
how this would impact routing scalability. Any ideas?
Fred
[EMAIL PROTECTED]
Ralph Droms wrote:
At 10:00 PM 8/21/2003 -0700, Tony Hain wrote:
This is a clear capability advantage that IPv6 brings over IPv4.
The only
I agree with Keith that the vote meant stop using SLs. I don't think
there is any reason to believe the vote was taken to answer the question
stop using SLs because XXX. People often choose to vote the same way as
others on a specific issue for many different reasons.
We could have asked several
At 09:26 AM 8/22/2003 -0700, Tony Hain wrote:
Ralph Droms wrote:
Tony - (assuming they == IPv6LL) can you explain why IPv6LL
will work while they don't work in IPv4? My experience
with IPv4LL has been uniformly bad; I've never intentionally
used an IPv4LL address and the automatic assignment
At 10:00 PM 8/21/2003 -0700, Tony Hain wrote:
This is a clear capability advantage that IPv6 brings over IPv4.
The only thing holding it back is the obstinate views of those who don't
want to make the scenarios work. After-all they don't work in IPv4, so they
must not be really needed, right???
Agreed - there are significant potential savings. Does it work?
- Ralph
At 08:56 AM 8/14/2003 -0400, Keith Moore wrote:
Another potential advantage for IPv6 that is a little harder to quantify is
the notion of graceful renumbering - the ability to have a transition
state in which both the
Taking Carlos' analysis a step further, there are two kinds of stuff that
has to be fixed during a renumbering event: stuff that can be fixed
automatically (cost essentially independent of network complexity) and stuff
that has to be fixed manually (cost that scales with network complexity).
For
I've reviewed the minutes from the ipv6 WG meeting in SF and those minutes
reflect my memory that the question about deprecating site-local addresses
was put to the WG independent of any consideration of a replacement
mechanism. Clarifying e-mail to the ipng mailing list from Margaret
(3/28/2003)
Regarding reverse DNS entries ... there is a specific problem
with reverse DNS entries for autoconfiguration addresses regarding
update of the reverse entries by the client.
The portion of the DNS namespace into which the host wants to
insert its reverse DNS entry is owned by the network to which
I agree with kre - address configuration through DHCP (confrolled
by 'M' bit) and autoconfiguration through advertised prefixes
should be considered independent. An interface may well have
both autoconfiguration addresses and addresses obtained through
DHCP (and manually configured addresses, as
Margaret,
Sorry to ask a question for which the answer might be obvious...
You wrote:
At 02:37 PM 4/1/2003 -0500, Margaret Wasserman wrote:
NOTE: DO NOT reply if you already expressed an opinion during
the IPv6 WG meeting in SF!
Does expressed an opinion mean stepped to the mike and
spoke or
We have a stateless DHCPv6 server and client in IOS. They are both pretty
lightweight - both to implement and to configure. I'm going to go off this
afternoon and try to develop a more quantitative measure of lightweight.
- Rlaph
At 07:11 PM 3/19/2003 +0100, Stig Venaas wrote:
On Mon, Mar
Regarding conflicting DNS information - in theory, it shouldn't matter if
there is conflicting information about DNS servers, as the host would
receive the same response to a DNS query send to any of the DNS servers.
I am DNS-naive and my comment about in theory may well be wrong, either
in
I guess the next rev of the draft should change the text to indicate the
use of NotOnLink.
- Ralph
At 05:19 PM 3/12/2003 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
On Sat, 08 Mar 2003 23:16:31 +,
Ole Troan [EMAIL PROTECTED] said:
[snip]
It would also be helpful
At 09:06 AM 3/12/2003 +0200, Pekka Savola wrote:
On Tue, 11 Mar 2003, Bound, Jim wrote:
In addition the Enterprise wireline networks and IT are not going to
give up stateful control with servers and NAS in their networks for a
long time with IPv6 is my intelligence from my work with users.
Are
I've revised DNS Configuration options for DHCPv6 to be published as
draft-ietf-dhc-dhcpv6 opt-dnsconfig-03.txt based on input received during
the WG last call. Here is the summary of changes to the document:
Changes from draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
This document includes
We did some interoperability testing of independent DHCPv6 implementations
at the recent TAHI interoperability testing event. I've published a list
of issues, draft-ietf-dhc-dhcpv6-interop-00.txt, identified through the
interoperability testing.
The DHCPv6 specification has been accepted as a
://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt
- Ralph Droms
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
Summary of discussion during WG last call on
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with
editorial suggestions. These suggestions have been incorporated into the
draft and will appear in next published rev.
Peter Koch
, at 10:25 PM, Pekka Savola wrote:
On Thu, 20 Feb 2003, Alain Durand wrote:
On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote:
If it's unclear, then we should edit the document to explicitly
identify the addresses as IPv6 addresses.
This option is intended to return IPv6 configuration
DHCPv6 specification, and is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
- Ralph Droms
IETF IPng Working Group Mailing List
IPng Home Page: http
Thanks for your feedback, Peter; my comments in line...
- Ralph
At 08:27 PM 2/10/2003 +0100, Peter Koch wrote:
draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for
DHCPv6: the Domain Name Server option and the Domain Search List
This document uses terminology specific to
and its
family.
- Alain.
Ralph Droms wrote:
Reminder and note: there have been a few responses to this WG last call,
but no explicit positive recommendations for advancement.
Please review draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with
comments. If you recommend the document
-delegation-02.txt
- Ralph Droms
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
-dhc-dhcpv6-opt-prefix-delegation-02.txt
- Ralph Droms
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Tony,
Thanks for the feedback...I've responded in line.
- Ralph
At 08:58 AM 2/7/2003 +0100, EAB wrote:
In chapter 6. Appearance of these options
'The Domain Name Server option MUST appear only in the following messages:
Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request,
, Pekka Savola wrote:
On Wed, 5 Feb 2003, Ralph Droms wrote:
DHCPv6 draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt. The last call will
conclude on Friday, 2/21.
Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs.
draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two
Roy - thanks for noticing the omission of manually configured
addresses. Your revised text looks fine to me.
- Ralph
At 11:07 AM 2/7/2003 -0500, Roy Brabson wrote:
Not knowing the background of all readers of the doc, it might be good
to
put your explicit warning in the text:
An IPv6
Jari,
At 03:14 PM 2/6/2003 +0200, Jari Arkko wrote:
[snip]
Maybe the right thing is to attach a warning or an explanation
about the implications and leave the support as a MAY. For
instance,
Nodes that do not implement DHCP may become unable to
communicate outside the link when their
Jari - I liked the way your text was explicit about the consequences of not
obtaining a global address through DHCP when no stateless autoconfig
prefixes are advertised:
Nodes that do not implement DHCP may become unable to
communicate outside the link when their routers advertise
John,
I've reviewed the text in draft-ietf-ipv6-node-requirements-02.txt, and I
have some comments about the text concerning DHCP.
Regarding the use of DHCP for address assignment...RFC2462 is somewhat
vague about the requirement - there are no RFC2119 words guiding the ues of
DHCP in section
.txt
- Ralph Droms
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
: ext Ralph Droms [mailto:[EMAIL PROTECTED]]
Sent: 21 November, 2002 14:56
To: Greg Daley; Loughney John (NRC/Helsinki)
Cc: Bound, Jim; [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipv6-node-requirements-01.txt
There may be some additional discussion about the 'M' and 'O'
bits during
my slot
There may be some additional discussion about the 'M' and 'O' bits during
my slot in the ipv6 WG meeting Thu AM.
- Ralph
At 12:09 PM 11/21/2002 +, Greg Daley wrote:
Hi Jim,
I find it hard to tell if you mean it is wrong (incorrect) or
wrong (not the right way to go).
about the current
I support this suggested course of action and the proposed new text.
- Ralph
At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote:
Unfortunately it's too late to catch the addressing architecture
document unless we recall it from the RFC Editor and cycle it
through the IESG again. But I
At 11:10 AM 11/8/2002 -0500, Brian Haberman wrote:
BELOEIL Luc FTRD/DMI/CAE wrote:
Does anyone think that a validity lifetime should be associated to the
prefix during prefix delegation?
Absolutely.
I agree - but with a slight clarification: the delegator associates an
expiration time with
At 08:39 AM 11/7/2002 -0500, Keith Moore wrote:
I don't follow your analogy. Let me try one of my own. Expecting
apps to use SLs is like expecting that someone who is married to
a person named mary will be equally satisfied with the person
named mary in whatever town he happens to be in
sites that each use site-local
addresses?
- Ralph
At 12:25 PM 10/31/2002 -0800, Tony Hain wrote:
Ralph Droms wrote:
...
Adjacent nets that both use SLs is an interesting (potentially
problematic?) architecture - I would be interested in finding
out about
deployment experience with that case
are not part of the site (so that it doesn't forward site
locals).
- Ralph Droms
At 12:23 PM 10/30/2002 -0800, Michel Py wrote:
Margaret Wasserman wrote:
If you can compromise the edge router and change its
configuration, you can get either intra-site global
or site-local traffic to be forwarded
Based on the comments and questions about the intended use for this
proposed mechanism, I suggest some clarification might be needed to explain
that (if I have this correct) this mechanism:
* is intended for ongoing use (not
just for bootstrapping)
* is intended to populate a stub resolver's
At 03:33 PM 6/27/2002 -0400, Brian Haberman wrote:
Keith,
Keith Moore wrote:
if you have enough bits for the site-id you can make the probability
of a conflict approach zero *provided* the site bits are randomly
chosen. but the easiest way to avoid conflicts is to make the
site-id
I agree 100% with Micehls' point - assigning unique IDs to sites for use in
site-local addresses moves the site-local addresses into a globally
routable address space, with the additional feature that those addresses
are provider independent. The result would be an address space that is
DHCPv6 currently uses a site-scoped multicast address as the default for
forwarding messages from a relay agent to servers. The relay agent can be
configured with a list of unicast addresses for servers instead of using
the site-scoped multicast address.
DHCPv6 also depends on link-local
Toshi,
Is DHCPv6 (configuration-only or stateless DHCPv6) a viable option for
host configuration - are there now or will there be hosts with DHCPv6 for
those home networks where the O bit is set?
- Ralph
At 11:33 AM 5/20/2002 +0900, Toshi Yamasaki wrote:
Hi, Juha!!
Yes, this is one of the
At 09:49 AM 5/3/2002 -0700, Steve Deering wrote:
A couple questions, from one who is expert in neither DNS nor DHCP:
Do the bulk of DHCP servers today provide more than one DNS server
address to each client?
Yup.
If so, do consumer-level IP devices (PCs,
laptops, PDAs, cell phones, etc.) really
Which ID do you mean by anycast listener discovery document?
draft-vida-mld-v2-02.txt?
- Ralph
On Thu, 2 May 2002 [EMAIL PROTECTED] wrote:
What do we think we need to do to get the requirement that only
Routers can have anycast addresses changed to nodes.
see section 3.1 of
Are the MLD extensions for anycast written up somewhere?
- Ralph
At 03:56 PM 4/30/2002 +0200, Hesham Soliman (ERA) wrote:
b) What's the security model by which the router decides
whether to
accept routing updates from the DNS server?
The same model that is used
We've made a proposal in the latest rev of the DHCPv6 draft to use a
well-known, site-local anycast address.
- Ralph
At 12:54 PM 4/29/2002 -0700, Steve Deering wrote:
At 2:27 PM -0400 4/29/02, Rob Austein wrote:
I have to admit that I also find it kind of amusing that this of all
WGs seems
At 12:54 PM 4/29/2002 -0700, Steve Deering wrote:
At 2:27 PM -0400 4/29/02, Rob Austein wrote:
I have to admit that I also find it kind of amusing that this of all
WGs seems to be proposing to move service location functionality out
of the edge systems and into the network core.
No more so
Keith,
At 04:35 PM 4/23/2002 -0400, Keith Moore wrote:
3. If interpreted as absolute, binary requirements, 7 and 8 are
quite likely fantasies. I intend 7 and 8 to be goals that proposed
solutions can be measured against.
I guess I don't see this as a very useful yardstick because
'no
Here's my cut at a list of requirements for DNS Configuration. It's based
on Bob's IPv6 DNS Discovery Requirements Statement, previous discussions
on DNS configuration, and my own $0.02. My intention is to list all of
the requirements I've heard in the various discussions about DNS
Keith - I think we might actually be more in agreement than
disagreement. You have pointed out several places where I wasn't clear;
let me see if I can clarify...
One global clarification - I used the term requirements in the sense I
often see the term (mis)used. What I've written is more a
Thanks, Bob, for writing a draft doc on DNS Discovery requirements. We
need something concrete to center this discussion.
So, here are some discussion points around the draft doc...
Is a server-less solution the best solution for DNS Discovery?
I think the third scenario is likely to be problematic.
My understanding is that your third scenario would
require that the customers' networks all be part of
the same site as the ISP network - at least as far in
as a DNS server somewhere. I imagine some ISPs
might want to draw a site boundary
Either the CPE or the provider edge device could perform a
relay function. The relay function is not described as
part of draft-ietf-ipv6-dns-discovery-04.txt. How, exactly
would it work?
In my opinion, the relay function defeats the zero
configuration goal of the DNS Discovery mechanism, as
A couple of issues came out of the discussion of the prefix delegation
option in Minneapolis:
* Disallow reassigning delegated prefix on upstream link (and
should this restriction be configurable?)
* Allow use of DHCP on NBMA links by reserving a well-known
anycast address for
I read through RFC 2462 to find out the requirements level for host use of
the 'O' flag field (other stateful configuration) in RAs. The only text
I found concerning the 'O' flag is
(section 4, Protocol Overview)
Solicitations to the all-routers multicast group. Router
Pekka,
Thanks for the suggestion about separating the drafts. There is a need to
more clearly specify what is required for configuration-only DHCP
service. (There is also a need for a better name; suggestions, anyone?)
I agree with Bernie that writing two separate specs wouldn't be a good
Text specifying the appropriate behavior (as Steve describes) on the part
of DHCP servers will be added to the next rev of the DHCPv6 spec...
- Ralph
At 01:02 PM 3/18/2002 -0800, Steve Deering wrote:
At 3:23 PM +0100 3/17/02, Alberto Escudero-Pascual wrote:
(MUST, SHOULD) the (stateful)
At 02:28 PM 3/7/2002 -0500, Rob Austein 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
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
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
With all due respect, I've read draft-prigent-dhcpv6-threats-00.txt. The
authors based this doc on an old draft of the DHCPv6, which they did not
understand very well.
- Ralph
At 02:39 PM 3/7/2002 +0100, Francis Dupont wrote:
In your previous mail you wrote:
But I don't really care
At 05:52 PM 3/7/2002 +0100, Francis Dupont wrote:
In your previous mail you wrote:
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
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
You can find a pre-publication version of the DHCPv6 (rev -23) spec at
www.dhcp.org/dhcpv6-23 This rev has fixes made in response to comments
received during the WG last call. I will post a diff of the -22 and -23
(doc source) later today, along with a summary of the changes. The changes
The following issues were raised during the last call for the DHCPv6 spec
draft-ietf-dhc-dhcpv6-22.txt; I will kick off separate discussion threads
for each open issue later today.
- Ralph Droms
Open issues
---
* We've experienced a proliferation of DHCPv6 options. Should all
Bernie - I've been in allday meetings Mon and Tue, and more meetings for a
good part of today.
I put together the following message to send to the dhcwg and ipng mailing
lists, summarizing the comments during the last call. There is one more
batch of comments from Vijay Bhaskar A K that I
Please ignore my previous message to this list - I'll post a complete
summary of the discussion of the DHCPv6 draft tomorrow.
- Ralph Droms
IETF IPng Working Group Mailing List
IPng Home Page: http
to the DHC WG mailing list, [EMAIL PROTECTED]
- Ralph Droms
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
If you've reviewed the most recent rev of the DHCPv6 spec
draft-ietf-dhc-dhcpv6-22.txt, please post your comments to [EMAIL PROTECTED]
- even if your comments are as brief as looks ready for submission for
Proposed Standard...
- Ralph Droms
At the IPv6 WG meeting (Thu AM) in Salt Lake City, I mentioned that the
DHCPv6 spec is about ready for WG last call. I've included a message below
that I sent to the DHC earlier today. I invite and encourage the IPv6 WG
to review and comment on draft-ietf-dhc-dhcpv6-22.txt in the [EMAIL
We're likely to see a lot of those small sites without a DNS server, run by
unsophisticated users. Our recent experience with small IPv4 sites - SOHO
behind a CPE box (router/NAT) - is that they are very likely to include a
light-footprint, full-function, low-configuration DHCP server. Those
Until the -21 version is published at ftp.ietf.org, you can get the latest
DHCPv6 draft at www.dhcp.org
- Ralph Droms
At 10:42 AM 11/30/2001 +0100, Martin Stiemerling wrote:
You might be interested in DHCPv6. Try the DHCPv6 Internet Draft.
One location is
This is outdated! The newest
The Inform message is defined in the -21 rev of the DHCPv6 spec, which was
submitted before the publication deadline last week but has not yet been
published at www.ietf.org. You can get a copy from www.dhcp.org now...
- Ralph
On Thu, 29 Nov 2001 [EMAIL PROTECTED] wrote:
a comment on
75 matches
Mail list logo
