Hello,
I'll take one particular issue, and Cc: to multi6 as I believe it is a
very important thing to consider.
On Fri, 14 Feb 2003, Alan E. Beard wrote:
Most of the end-user-network managers among my clients now multihome,
and
will continue to require multihomed service in future.
On Thu, 2003-02-20 at 10:32, Pekka Savola wrote:
This is a very problematic approach IMO.
Need more resiliency? Network outages unacceptable?
The right place to fix this is the network service provider, period.
Nothing else seems like a scalable approach.
In a perfect world I'm sure
On Thu, 20 Feb 2003, Iljitsch van Beijnum wrote:
On Thu, 20 Feb 2003, Pekka Savola wrote:
Your comment may be true, but my clients are nonetheless unwilling to risk
the possibility of an extended network outage on a single ISP (while not
frequent, these events are far from
Michel Py wrote:
RFC2374 was the definition of addresses for Format Prefix 001
(2000::/3) which is formally made historic by this document. Although
as specified in [ARCH] IANA should limit the IPv6 Global Unicast
| address space to 2000::/3 for now, IANA might later delegate
| currently
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 for advancement without revision, please respond
From a quick look at the draft:
4. Domain Name Server option
The Domain Name Server option provides a list of one or more IP
addresses of DNS servers to which a client's DNS resolver MAY send
DNS queries [2]. The DNS servers are listed in the order of
preference for use by the client
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
On Thu, 20 Feb 2003, Iljitsch van Beijnum wrote:
On Thu, 20 Feb 2003, Pekka Savola wrote:
We are _very_ far from a situation where even the best ISP provides a
service level that is better then the one you get from multihoming even
if you consider failover delays.
In some cases, this
On Thursday, February 20, 2003, at 12:03 PM, Ralph Droms wrote:
Alain,
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 information.
IPv4 addresses for DNS resolvers should be
Oddly enough, from the same premises we arrived to opposite conclusions!
If you leave the space out of 2000::/3 as 'unassigned' and I'm an
implementor, I may put special code when sending a unicast
packet to make sure that SRC DST addresses are within the valid
range...
- Alain.
On Thursday,
Hello,
Sorry for the delay in responding.
On Tue, 18 Feb 2003, Erik Nordmark wrote:
1) draft-haberman-ipngwg-host-anycast-01.txt (Host-based Anycast using
MLD) -- May 2002.
== basically the MLD protocol is used to signal anycast joins/leaves.
However, critical part which seems to be
On Thursday, February 20, 2003, 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
Finally, the reasons for not peeking at the actual
link layer addresses used in the link layer frame can
be summarized as follows:
6. Separation of function
This again follows the architectural principle.
Especially, it was viewed that checking the
link-layer
On Thu, 20 Feb 2003, Alain Durand wrote:
On Thursday, February 20, 2003, 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
I thought I had said that I thought it should go ahead, but maybe not
explicitly. I would like to see this draft advance.
IETF IPng Working Group Mailing List
IPng Home Page:
Alain,
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 information. IPv4
addresses for DNS resolvers should be provided through DHCPv4...
- Ralph
At 11:40 AM 2/20/2003 -0800, Alain
16 matches
Mail list logo