ISP failures and site multihoming [Re: Enforcing unreachability ofsite local addresses]

2003-02-20 Thread Pekka Savola
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.

Re: ISP failures and site multihoming [Re: Enforcingunreachability of site local addresses]

2003-02-20 Thread Lars Erik Gullerud
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

Re: ISP failures and site multihoming [Re: Enforcing unreachabilityof site local addresses]

2003-02-20 Thread Pekka Savola
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

Re: IPv6 WG Last Call onIPv6 Global Unicast Address Format for the 2000::/3 Prefix

2003-02-20 Thread Alain Durand
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

WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Ralph Droms
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

Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Alain Durand
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

Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Ralph Droms
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

Re: ISP failures and site multihoming [Re: Enforcing unreachabilityof site local addresses]

2003-02-20 Thread Pekka Savola
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

Re: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Alain Durand
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

Re: IPv6 WG Last Call onIPv6 Global Unicast Address Format for the 2000::/3 Prefix

2003-02-20 Thread Alain Durand
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,

Re: a few comments on anycast mechanisms

2003-02-20 Thread Pekka Savola
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

Re: [dhcwg] Re: WG last call ondraft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Alain Durand
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

Re: Summary: Reason for the explicit link-layer address options in ND?

2003-02-20 Thread Erik Nordmark
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

Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Pekka Savola
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

Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Ted Lemon
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:

Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

2003-02-20 Thread Ralph Droms
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