Similar discussion has already been had, so I'll try to keep it at the
minimum.
On Mon, 24 Feb 2003, Ralph Droms wrote:
> At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote:
> >On Tue, 11 Feb 2003, Ralph Droms wrote:
> > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6
> > >
On Mon, 24 Feb 2003, Vijayabhaskar A K wrote:
> > That is, the requesting router is in charge of all the prefixes until
> > they expire. The robust requesting router implementation will perform
> > some sane refreshing of these bindings way before they expire, even
> > periodically.
> >
> > Thus,
On Mon, 24 Feb 2003, Michel Py wrote:
> > Kurt Erik Lindqvist wrote:
> > This I thought was more or less standard. I was talking about
> > less than 100ms convergence.
>
> Dude, this requires a keepalive or hello at 10ms intervals and a 25~30
> ms rtt. You might need to talk to a guy named Albert
> Kurt Erik Lindqvist wrote:
> This I thought was more or less standard. I was talking about
> less than 100ms convergence.
Dude, this requires a keepalive or hello at 10ms intervals and a 25~30
ms rtt. You might need to talk to a guy named Albert Einstein; he wrote
interesting RFCs about the spee
On Fri, Feb 14, 2003 at 05:14:41PM +0200, Jari Arkko wrote:
>
> I'm trying to understand what the following text means and
> implies in Section 3.3 of RFC 3041:
>
> "Note: because multiple temporary addresses are generated from the
>same associated randomized interface identifier, there is
FYI.
A draft has been submitted in the 'mobileip' wg to discuss
extension of IPv6 socket APIs for MIPv6.
The draft includes mechanism :
* to observe MH(Mobility Header) packets at the user level
* to access HOA and Routing header type 2 at the user level
* Defines MH protocol in /etc/prot
We have had discussion about requirement of having a socket-API
on source address selection, in this alias.
A draft has been submitted to address source address selection at
the per-socket (and per apps) basis. Currently it discusses preferences
of source address selection by the application for p
Hi Fred.
> The main message I am getting is that the "L" bit is a don't-care from
> the standpoint of RFC 2462 section 5.5, and I agree that that point needs no
> further clarification. But, I'm still a bit uncertain on the following point:
> Thomas Narten wrote:
> > This question applies to any
Thomas et al,
The main message I am getting is that the "L" bit is a don't-care from
the standpoint of RFC 2462 section 5.5, and I agree that that point needs no
further clarification. But, I'm still a bit uncertain on the following point:
Thomas Narten wrote:
This question applies to any address
Title: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
Isn't it possible for the DHCPv6 server to return IPv4 addresses as per
RFC 2373, section 2.5.4 (IPv6 Addresses with Embedded IPv4 Addresses),
in particular:
A second type of IPv6 address which holds an embe
Erik,
>>Michel Py wrote:
>> Proposed text:
>> 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
Pekka,
Thanks for your review and feedback on
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02
My comments are in line...
- Ralph
At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote:
On Tue, 11 Feb 2003, Ralph Droms wrote:
> draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt describes new DHCPv6
> o
My comments inline
~ Vijay
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Pekka Savola
> Sent: Sunday, February 23, 2003 11:56 PM
> To: Vijayabhaskar A K
> Cc: 'Ralph Droms'; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [dhcwg] Re: WG last
On Mon, 2003-02-24 at 16:57, Erik Nordmark wrote:
> What about the case when you have UDP communication which needs to reach
> the same server? (or at least be notified when the anycast server changes).
> In that case you can't rely on the fact that the kernel has a single notion
> of active commun
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
> On Mon, 24 Feb 2003 08:51:01 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Please ignore the first sentence of this reminder - it was queued for
> transmission before the round of discussion that began at the end of last
> week...
>> Reminder and note: there has been not response
To talk about resilience is a snare for the unwary until you specify
what you are providing resilience against.
The large enterprises I work with have a simple policy, set by the
non-technicians who run the organisation; no single point of failure.
That doesn't mean no single point of failure in t
On Mon, 24 Feb 2003, Erik Nordmark wrote:
> > For connection-less protocols, source address should not matter, that
> > much.
>
> The fact that UDP is a connection-less layer 4 protocol doesn't mean
> that there aren't protocols above it which assume that they
> continue to talk to the same peer
> For connection-less protocols, source address should not matter, that
> much.
The fact that UDP is a connection-less layer 4 protocol doesn't mean
that there aren't protocols above it which assume that they
continue to talk to the same peer (until communication fails).
Erik
> > Depends what happens when the binding times out and
> > needs to be refreshed/re-established.
> > MIPv6 assumes that it can just redo the RR exchange and
> > still end up sending to the same host. That isn't the case for
> > anycast since the anycast address identifies more of a service than a
Please ignore the first sentence of this reminder - it was queued for
transmission before the round of discussion that began at the end of last
week...
- Ralph
At 08:00 AM 2/24/2003 -0500, Ralph Droms wrote:
Reminder and note: there has been not response to this WG last
call. Please review dr
Reminder and note: there has been not response to this WG last
call. Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and
reply with comments. If you recommend the document for advancement without
revision, please respond with a quick acknowledgment. No response will be
inter
There is no technical reason why a single service provider network
can
do better than a similar network that consists of several smaller
See Abha and Craigs paper on convergence of BGP. Personally I would go
for a large provider with multiple connections.
Based on this paper? What I see is rarely
23 matches
Mail list logo
