Hi
James Kempf wrote
> If the mobile node is
> capable of detecting when the link changes, it can immediately send an RS rather
> than wait for a multicast RA.
According to RFC 2461, mobile host should not send RS immediately. Before sending
RS, it should execute random delay like below.
"Be
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : IP Version 6 over MAPOS
Author(s) : T. Ogura, M. Maruyama, T. Yoshida
Filename: draft-ogura-ipv6-mapos-01.txt
Pages : 12
Date
Margaret Wasserman wrote:
>
>
>> The more I think about it, the more I realize that "automagically"
>> creating the subnet-local scope zone id isn't going to work.
>> Especially with multiple prefixes per interface.
>
>
> So, this would be consistent with the suggestion that we
> change the Ad
Title: RE: I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt
Hi,
I've recently published an ID (see below), which aims at identifying the requirements to deploy IPv6 unmanaged networks, from an ISP point of view. This work encompasses topics that are (could be) addressed in the ipv
Greg
Greg Daley wrote:
> Hi Vlad,
>
> I'm not sure that there is a requirement to use a fastra flag.
>
> There may be situations where multiple nodes come up on a link
> in the duration between multicast advertisements but this may be
> handled by the MAX_FAST_RAS being set high enough to handl
> I'm not sure that we are loosening that. The rest of the quoted
> paragraph reads:
>
> "If a host has already performed
>a random delay since the interface became (re)enabled (e.g., as part
>of Duplicate Address Detection [ADDRCONF]) there is no need to delay
>again before sendin
> > I'm not sure that we are loosening that. The rest of the quoted
> > paragraph reads:
> >
> > "If a host has already performed
> >a random delay since the interface became (re)enabled (e.g., as part
> >of Duplicate Address Detection [ADDRCONF]) there is no need to delay
> >again
Title: RE: Changing RS Reply Timing for Mobile IPv6
I'm not sure that we are loosening that. The rest of the quoted
paragraph reads:
"If a host has already performed
a random delay since the interface became (re)enabled (e.g., as part
of Duplicate Address Detection [ADDRCON
> From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> >> The more I think about it, the more I realize that "automagically"
> >> creating the subnet-local scope zone id isn't going to work.
> >> Especially with multiple prefixes per interface.
Why not? Can you elaborate?
Shouldn't it always be tru
Hi,
I have one question about multihomed host.
In the multi6 WG charter, there is the following definition
for multihomed "site":
A multihomed site is a site that has more than one connection to the
public internet with those connections through either the same or
different ISPs. Sites c
>
>
>Is there any definition for multihomed "host"?
I don't know if there is an official definition, but I
have usually heard the term "multihomed host" used to
refer to multi-interface systems that do not function
as routers (i.e. they don't forward packets).
Margaret
Thanks for your quick response.
There may be some scenario in which a single-interface host is connected
to multiple ISPs on the same link, which seems to be not covered in
the usual definition for "multihomed host".
I don't know what to call the model, but is such a model already
common? Or i
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).
For what it's worth, I've occasionally heard the term used in an
application-lay
Dave Thaler wrote:
>>From: Brian Haberman [mailto:[EMAIL PROTECTED]]
>>
The more I think about it, the more I realize that "automagically"
creating the subnet-local scope zone id isn't going to work.
Especially with multiple prefixes per interface.
>>>
>
> Why not? Can you elaborate?
> -Original Message-
> From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 09, 2002 1:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: IPv6 subnet-local addresses and
draft-ietf-ipngwg-addr-arch-
> v3-10.txt
>
> Dave Thaler wrote:
> >>From: Brian Haberman [mailto:[EMAI
> Yoshihiro Ohba wrote:
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).
Here is my reading of this:
1. Multi-interface host:
>
> For v4, I agree with Bill *if* the multiple addresses belong to
> different subnets.
>
> For v6, this is blurry. Would you call multihomed a host that has both a
> link-local and a regular unicast address on the same interface? I don't
> think so.
>From the point of view of what applications n
> Bill Sommerfeld wrote:
> From the point of view of what applications need to do,
> it's safest to assume that all V6 hosts are multiaddressed.
Strongly agree. Although multiaddressed does not necessarily mean
multihomed, it is likely that part of the multihoming solution is
multiadressed hosts.
Thank you all for helping me understand.
I have additional question below.
On Wed, Oct 09, 2002 at 03:21:34PM -0700, Michel Py wrote:
> On the other hand,
> > Yoshihiro Ohba wrote:
> > There may be some scenario in which a single-interface
> > host is connected to multiple ISPs on the same link,
Dear IPv6 WG:The following draft is
posted newly in the drafts
directory http://www.ietf.org/internet-drafts/draft-lee-optimal-detect-pmtu-00.txt
Title : Optimal Detecting Increases in PMTU
Author(s) : HAK GOO LEE, PYUNG SOO
KIM, YOUNG KEUN KIM, CHU KYO SHIN
Abstract : This doc
Hi Brett
Thanks for your kind comment.
As you may know, random delay of RS is 'to alleviate congestion'
as the following states:
" This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure."
Therefore, we
Hi Vlad,
Vladislav Yasevich wrote:
> Greg
>
> Greg Daley wrote:
>
>> Hi Vlad,
>>
>> I'm not sure that there is a requirement to use a fastra flag.
>>
>> There may be situations where multiple nodes come up on a link
>> in the duration between multicast advertisements but this may be
>> handled
> In summary, the draft amends RFC 2461 to allow at most one router on
> a link to reply immediately to an RS instead of waiting a random
> amount of time between 0 and MAX_RA_DELAY_TIME. The router is
> allowed to reply to at most MAX_FAST_RAS since the last unsolicited
> multicast is sent. If th
>>> Yoshihiro Ohba wrote:
>>> There may be some scenario in which a single-interface
>>> host is connected to multiple ISPs on the same link, which
>>> seems to be not covered in the usual definition for
>>> "multihomed host". I don't know what to call the model,
>>> but is such a model already co
24 matches
Mail list logo
