Hi Wen,
> 802.21 is developing standards to enable handover and
> interoperability between heterogeneous network types including both
> 802 and non 802 networks. 802.21 is running below IP layer.
> However, SAAC procedure is running in IP layer.
802.21 is designed to run over L3/L4 transpor
uld happen? Fortunately, I don't think we have
> to worry about such a scenerio in this case, because the company
> in question is pretty large and in no danger of being taken over.
>
> jak
>
> - Original Message -
> From: "Greg Daley" <[EMAIL PRO
available in the USA at the
time (as far as I can tell).
Greg
Greg Daley wrote:
Hi Margaret,
I'm not sure how this affects the IPR notification,
but I've had a quick look at existing art available
at the time of the patent application.
There are existing specifications of IPv6 auton
no reference
to them in the description of the patent, made at application time.
Clearly, I'm not able to provide legal advice about this
situation, but the above information may be able to help someone
who is.
Greg Daley.
Margaret Wasserman wrote:
FYI --
The official disclosure will prob
Hi Syed,
Syed Ajim Hussain wrote:
Hi
Francis/Jhon
Thanks for your information. Why IPv6 Broadband access service is so
dependent on DHCP6. Even if you run DHCP6-Relay on NAS there is some
problem in NAS for maintaining Route-information, Since NAS does not
know
What prefixes are alloca
Hi Marcelo,
- Original Message -
From: marcelo bagnulo braun <[EMAIL PROTECTED]>
Date: Saturday, August 13, 2005 0:50 am
Subject: Re: Solutions for distributing RFC 3484 address selection
policies
> Hi Greg,
>
> El 12/08/2005, a las 2:14, Greg Daley escribió:
> >
Hi Ralph,
Ralph Droms wrote:
On Thu, 2005-08-11 at 01:40 -0400, timothy enos wrote:
[...]
One thing is that in using DHCPv6, all DHCPv6 clients on the link will
get the same policy. Also, IMO it wouldn't always be bad for all hosts
on a link (DHCPv6 or otherwise) to get the same policy.
It'
Hi Tim,
timothy enos wrote:
[cut]
It is worth noting, that in the DHC proposal, 24 bits of data:
(label, precedence, zone-index) are added which aren't present
in PIOs.
There's an unused 32 octet field available (and another 5 unused
bits for flags) in each PIO, which are currently unused.
A
Hi Bernie.
Bernie Volz (volz) wrote:
It's unclear at the moment how a DHCP server on one link is able
to describe how to use addresses available on another interface
or link.
Why would you then assume that an RA on one link could do any more? It
too would be restricted to providing policies J
Hi Mark,
Mark K. Thompson wrote:
Hi,
On 9 Aug 2005, at 11:53, Arifumi Matsumoto wrote:
On 2005/08/09, at 5:40, Mark K. Thompson wrote:
the lack of field definition for labels has seen different OSes use
different datatypes for the label, from string through
stringified-integer to integer
Hi
[EMAIL PROTECTED] wrote:
[cut]
So a question then is whether that is enough or if there are
many cases where the full policy (including source address
selection) is needed. If the full policy is needed in some cases,
then we have to consider whether it's worth having two solutions.
I don't k
Dear Stig,
Stig Venaas wrote:
So far two principal solutions have been suggested, RAs and DHCP. If
people want to work on solutions we could possibly look into both of
these.
Some issues have already been mentioned on this list. Another issue
which was brought up in dhc wg, is that the policy i
Hi Tim,
timothy enos wrote:
[cut]
In that case, I think we
should try to look for possible solutions. Some applications might
want to specify their own particular behaviour, but I see several
reasons why an administrator may want to specify a default.
Using DHCP may be one solution. The only al
Hi Fred.
Fred Baker wrote:
On Aug 8, 2005, at 7:24 PM, Greg Daley wrote:
I'm not sure anyone is doing it, but renumbering is applicable there
as a means of providing information about which prefixes are valid.
One of the outcomes of the v6ops WG last week was the observation that
hich interacted with router discovery
to provide address selection policy would need to be integrated with
the ND messages, and the configuration systems applicable to those
messages.
Greg.
On Aug 8, 2005, at 4:58 PM, Greg Daley wrote:
Hi Mark,
Mark K. Thompson wrote:
[cut]
So, yes, I agree th
Hi Mark,
Mark K. Thompson wrote:
[cut]
So, yes, I agree that centralisation of address selection of policy is
important (and necessary for folks using ULAs with greater-than- site
scope multicast), and that DHCPv6 appears a reasonable choice, but
there are fundamental issues with RFC3484 t
Hi,
I was chatting with Keith Moore, and think that it may
help to provide guidance (a BCP) on which components
are stable and reliable for IPv6 deployment.
Perhaps it could be seen as a wrap-up for the IPv6 WG.
It may be possible to indicate the standard levels
at the time of writing, and indi
Hi,
I think there are some interesting discussions going on
in a different thread, but I thought I'd start a new thread
in order to talk about a contentious issue without polluting
the other.
Regarding draft-pashby-ipv6-network-discovery-00.txt,
this provides a mechanism for devices to be made
Hi Daniel,
None of the solutions has been accepted yet as a WG item.
The DNA goals draft (in RFC-ed queue) covers this issue,
and has a goal for fast reception of information (essentially RAs).
The RA delay issue is discussed in section 2.1 of 'dna-goals'
and is summarized in Goal: G2.
The cur
Hi Hesham,
(Cc: FastRA authors)
Daniel Park wrote:
So, to avoid the confusion, I'd like to ask the WG whether they agree that this
issue, addressed in draft-mkhalil-ipv6-fastra-04 (or later versions) should not
be included in the current work of 2461bis.
It seems DNA task in my opinion, t
Hi Christian,
I'll try to keep my response brief.
Christian Vogt wrote:
[cut]
Now going to specific points...
- its initial Router Solicitation after interface (re-)
initialization (D1) [RFC 2461bis] - joining the solicited-nodes
multicast address after interface (re-) initialization (D2)
Hi James,
James Kempf wrote:
[cut]
Actually, I wonder if what is needed is more of an applicability
statement saying what types of addresses it is appropriate to use this
procedure for, and where not. For example, can optimistic DAD be used
for the LL address? It took me some thinking to decid
Hi Thomas,
Thomas Narten wrote:
[cut]
BTW, what I meant to say above was more like:
This document requires that an implementation do things that may
logically (if you follow the conceptual sending model) be hard to
do, because the information needed to do something may not be
available
Hi Thomas.
Thomas Narten wrote:
I've reviewed this document and on the whole think it's fine for PS.
But I do have one general concern. This document requires that an
implementation do what in practice, I think might be "difficult" for
some implementations. While that is OK at one level, I fear
Hi Peter,
Grubmair Peter wrote:
Hi, sorry for bothering.
I would like to know how MLDv2 can currently work
Without being temporarily being forced to MLDv1 mode,
Even if all listeners have MLDv2 implemented.
RFC2461 (even the newest draft
)
Requires on page 56, chapter 7.2.1 interface initializa
Hi Hesham,
- Original Message -
From: "Soliman, Hesham" <[EMAIL PROTECTED]>
Date: Tuesday, March 8, 2005 10:35 pm
Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
> Hi Tatuya,
>
> I'm not sure what was said in the meeting but at least my intention
> was to use this text in add
Hi Martin,
[chop]
Perhaps it would be simpler just to add some text saying that
Ethernet NICs that do not support 33 multicast may not (cannot?) be
able to support v6?
"cannot" is too strict. IPv6 is a big thing. Only a certain form of
easy stateless autoconf is not supported if the 33 multicas
Hi Alex,
Alexandru Petrescu wrote:
Greg Daley wrote:
I think that Alex was thinking about end hosts which don't support IPv6.
YEs, hosts that support v4 ok and can't support v6 because of the 33
requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC).
Receiving an ini
Hi
Manfredi, Albert E wrote:
Alexandru Petrescu wrote:
Anyone proposed until now to update RFC2464 "IPv6 over Ethernet
Networks"? If not, I'd like to propose updating the following text:
An IPv6 packet with a multicast destination address DST,
consisting
of the sixteen octets DST[1] through D
Hi Jinmei,
JINMEI Tatuya / çæéå wrote:
On Mon, 21 Feb 2005 20:06:45 +0100,
Christian Vogt <[EMAIL PROTECTED]> said:
...to this...
[...] If there is no existing Neighbor Cache entry
for the solicitation's sender and a Source Link-Layer Address option
was present in the solicitatio
Hi Christian,
Christian Vogt wrote:
Hi Hesham,
hope this is not too late.
Not sure but the text may suggest to create NC state even if the RS did
not contain a SLLAO. In this case, it's actually not necessary to
create NC state, especially if the router chooses to respond with a
multicast RA.
clarifying statements?
Can we also agree or confirm (possibly conditionally on the
previous question) whether there's an agreement on text?
I'm not worried at the moment, since things seem to be
going the right way.
Greg
JINMEI Tatuya / çæéå wrote:
On Tue, 22 Feb 2005 16:26:26 +1100,
Greg D
at will reflect today's
default preference order.
Greg
Hesham
> -Original Message-
> From: Greg Daley [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 20, 2005 6:13 PM
> To: Christian Vogt
> Cc: Soliman, Hesham; ipv6@ietf.org; Mark Doll; Roland Bless
> Subject:
Hi Christian and Hesham,
I think people are asymptoting to the
same point.
Are we supposed to be suggesting text though?
Christian Vogt wrote:
Hi Hesham.
> [...]
> I guess this is why FreeBSD introduces a new state, NOSTATE. It does
> not do immediate address resolution on an entry in this stat
Hi Hesham,
- Original Message -
From: "Soliman, Hesham" <[EMAIL PROTECTED]>
Date: Saturday, February 19, 2005 2:21 pm
Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
> Hi Greg,
>
> I was definitely assuming that address resolution will
> take place in the case where the resp
Hi,
An update of the tentative source link-layer address options
draft is available.
The DNA design team is considering this as one of the
possible components of a DNA solution, but its applicability
is slightly wider.
Perhaps it can contribute to some of the issues discussion
on RFC2461bis.
Greg
-
Hi Hesham,
Soliman, Hesham wrote:
Christian,
Thanks for the detailed description. I think Nick brought this up
some time ago too.
My suggestion is that upon reception of an RS with no SLLAO the
router checks if an entry already exists, if none exists then it
creates one and puts it in STALE. I
Hi Rajan,
Rajan Srivastava wrote:
Hi Bhaskar,
Yes, you are right if we talk about a PPPv6 client inside a LAN.
But if I have a PPPv6 client running at my home PC, I can't do ND.
I will have to resort to a DHCPv6 client [implemented at my PC itself]!
Or is there any alternative?
ND runs over the PPP
Hi Rajan,
Rajan Srivastava wrote:
Hi Greg,
Thanks for the kind & prompt response.
What you mentioned is correct; but this kind of provision in IPv6 framework
has resulted in more complex implementations.
Eg., if PPP server would have allocated
one prefix to PPP client (in IPv6CP) then the client wo
those requiring networks/prefixes of addresses.
Each fills its own requirement, and it doesn't necessarily make sense
to define another way to do this in IP6CP, since the assumptions
are different to IPv4.
Yours Sincerely,
Greg Daley
being
discussed.
The concept has some different applications than just
replacing IPv6 (;-) and these are being discussed on the
[EMAIL PROTECTED] mailing list.
Greg Daley
Fred Templin wrote:
Hello,
With Nokia hat off, I would like to announce a proposal for IPng
called: "IPvLX - IP with virtual
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 18 Aug 2004 10:52:45 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
I'd like to be sure that's what we're doing though, by
explicitly stating that in the draft (or at least documenting
behaviours in such a case).
Same here. Ple
Hi Jinmei,
JINMEI Tatuya / wrote:
On Fri, 13 Aug 2004 11:15:48 +0200,
Stig Venaas <[EMAIL PROTECTED]> said:
Why? In this (i.e., the latter) scenario, does M=1/O=0 simply mean
that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
available but Information Request is not? Perhap
Hi Jinmei,
JINMEI Tatuya / wrote:
On Mon, 16 Aug 2004 14:13:14 +0530,
"O.L.N.Rao" <[EMAIL PROTECTED]> said:
I support the argument of optimizing NUD's RA processing.
However, the RS-RA exchange is not a frequent one to happen. Hence the
proposed optimization may not be of great adva
Hi Stig,
I think that some of the ideas which you present
are in accordance with some of the things I've been
thinking about.
I'm not strictly tied to one (M=3315/O=3736 or
M=Req,Renew.../O=Info Request) though. I think
that there are issues to be worked out based on
either course.
Stig Venaas wro
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 19:59:43 +0530,
Syam Madanapalli <[EMAIL PROTECTED]> said:
M/O flags indicate the avaialbility of the respective service, so if
a router advertises the M/O flags bits ON, I think we should OFF
them if and only if the same router advertis
Hi Fred,
Fred Templin wrote:
Greg Daley wrote:
For MTU, it's clear that you need to take the smallest
(most restrictive) value advertised. This is because
choice of a higher MTU is likely to have worse effects
than
I think this needs a bit of refinement. For multicast RAs (both unsolicite
Hi Syam,
Syam Madanapalli wrote:
[cut]
Indeed it is similar.
When you have trusted routers with differing configurations,
you have to make a decision what configuration to undertake.
For MTU, it's clear that you need to take the smallest
(most restrictive) value advertised. This is because
choice
Hi Jinmei,
JINMEI Tatuya / wrote:
On Thu, 12 Aug 2004 15:23:23 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an imp
Hi Ralph,
I was being imprecise (as usual).
I apologize for mis-representing the role of the RFC.
Ralph Droms wrote:
Greg - I have one minor disagreement with your explanation:
At 06:17 PM 8/11/2004 +1000, Greg Daley wrote:
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 14:16:03 +1000
Hi Jinmei
JINMEI Tatuya / wrote:
On Thu, 12 Aug 2004 14:51:59 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an imp
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 18:17:31 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
It's important to relize though that a host doesn't invoke
RFC 3736 procedures though. The host only cares that it wants to
do an Information-Request. 3736 is an imp
Hi Daniel,
S. Daniel Park wrote:
=> Right, but there is no need to have the O flag off. To me RFC 3736 is
something useful for server vendors and should not be associated with
setting the O flag.
You mean we can always set O flag ? I don't make sense why RFC3736
should not be associated with sett
Hi Syam,
Syam Madanapalli wrote:
- Original Message -
From: "Pekka Savola" <[EMAIL PROTECTED]>
To: "Syam Madanapalli" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Soohong Daniel Park"
<[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 2004 2:20 AM
Subject: Re: comments o
Hi Daniel,
S. Daniel Park wrote:
This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be available.
Not at all,,,Thanks your comments as well...:-)
At this stage, I think that the policy sec
Hi Jinmei,
JINMEI Tatuya / wrote:
On Wed, 11 Aug 2004 14:16:03 +1000,
Greg Daley <[EMAIL PROTECTED]> said:
This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be availabl
specific situations.
At this stage, I think that the policy section is OK except
for the imprecise usage of the terms 'stateless' and 'stateful'.
JINMEI Tatuya / wrote:
Hi, thanks for the prompt response.
On Thu, 05 Aug 2004 08:49:54 + (GMT),
Greg Daley <[EMAIL PRO
Hi Jinmei,
Sorry about the confusion.
- Original Message -
From: JINMEI Tatuya / <[EMAIL PROTECTED]>
Date: Thursday, August 5, 2004 7:31 am
Subject: regarding some comments on the M&O draft
> Hello,
>
> I'm not sure if I understand your comments on
> draft-daniel-ipv6-ra-mo-flags-
- Original Message -
From: Erik Nordmark <[EMAIL PROTECTED]>
Date: Wednesday, August 4, 2004 9:46 am
Subject: Editorial nits on draft-daley-ipv6-tsllao-00.txt
> Section 2.2:
> Some routers may choose to send a multicast response to devices
> which send Router Solicitations without S
Hi Erik,
Thanks for looking into this.
- Original Message -
From: Erik Nordmark <[EMAIL PROTECTED]>
Date: Wednesday, August 4, 2004 9:45 am
Subject: Multicast NS and draft-daley-ipv6-tsllao-00.txt
> Section 2,1 says:
> Hosts MUST NOT send Neighbour Solicitations with specified source
Hi Jinmei,
I'm not going to talk about the document itself.
JINMEI Tatuya / wrote:
[cut]
EDITORIAL COMMENTS
15. this draft uses the term "Neighbour", but for this particular term,
I guess we should stick to the US standard "Neighbor", because the
base documents such as RFC2461 use the latt
Hi Gerrit,
Gerrit van Niekerk wrote:
The question is directly related to ND and DAD because the "joining of the link-
local scope multicast groups" is specified in RFC2461 and RFC2462. It is now
clear to me that the reason is to inform MLD snooping switches rather than
routers about the multicast
Hi Hesham,
Soliman Hesham wrote:
Very sorry for the confusion. This text belongs
to a different issue. Eliminating the random
delay is NOT rejected.
I'm a bit confused now,
What's the staus of this issue, and what's the context?
Greg
---
I'm forwarding an announcement for an
individual submission I've made
Greg
--
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Preempting IPv6 Neighbour Discovery
Author(s) : G. Daley
Filename: draf
Hi Pascal,
Pascal Thubert (pthubert) wrote:
In any discovery this is going to be a problem, since
any discovery will require multicast at the MAC layer.
Note that if the hub and spoke quality of the 802.11 (enterprise mode)
network was not lost on the way of emulating ethernet, then the
discovery
Hi Masakata,
- Original Message -
From: Masataka Ohta <[EMAIL PROTECTED]>
Date: Wednesday, June 16, 2004 1:40 pm
Subject: Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS
Server)
> Hi, Greg;
>
> >>> If 802.11 was successfully emulating an Ethernet I would say
> yes.
>
> >>
Hi Masakata,
I think there is an issue of mis-communication
here which prevents us from moving beyond a certain
point in the conversation.
I understand what you're saying about different links having
different properties, and that individual hosts (on different
media) should take advantage of them.
Hi Masakata
Masataka Ohta wrote:
If 802.11 was successfully emulating an Ethernet I would say yes.
Broadcast over 802.11 is much less reliable than that over Ethernet.
PERIOD.
Actually multicast isn't, if the multicast packet
is only going toward the AP.
Greg
Hi,
Masataka Ohta wrote:
Hi,
However, with the current DHCPv6, it means that IP address should
be configured by DHCP with four messages.
I'm not so clear on your intention here, but I'd guess
that Stateless Address Autoconfiguration is OK, if there
is sufficient robustness in the (re)transmission
Hi,
Masataka Ohta wrote:
Hi Greg,
Anyway, back to the original topic, how do you think IPv6 hosts
should be configured with DNS server addresses?
I think you and Pascal are saying it's not ND but PPP. Right?
Actually, I think that DHCP is better (for recursive DNS
configuration).
Not so bad.
Th
Hi Masakata-san,
Masataka Ohta wrote:
Greg Daley wrote:
Hi Pascal,
I think we're straying from the original topic...
I think that infrastructure WLAN is point (not all statsions but
only the base station) to multipoint one.
Anyway, back to the original topic, how do you think IPv6 hosts
s
Hi Pascal,
I think we're straying from the original topic...
- Original Message -
From: "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]>
Date: Friday, June 11, 2004 11:24 pm
Subject: RE: WLAN (was Re: IPv6 Host Configuration of Recursive DNS
Server)
> Interestingly, part of this pain co
Hi,
Please be aware of a new draft from Erik, Nick and I.
Greg
---
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tentative Source Link-Layer Address Options for IPv6
Neighbour Discovery
Author(s)
Hi Pekka,
I'm not sure where this may lead, but...
- Original Message -
From: Pekka Savola <[EMAIL PROTECTED]>
Date: Tuesday, June 8, 2004 11:05 pm
Subject: Re: WLAN (was Re: IPv6 Host Configuration of Recursive DNS
Server)
> Tailed down mailing lists to just IPv6 WG list..
>
> On Tue
mistic
dad comments)
> Minor detail correction...
>
> > From: Greg Daley <[EMAIL PROTECTED]>
>
> > Please also be aware there is no issue for default router selection
> > on hosts, (which is what the IsRouter flag is for) since they never
> > receive
Hi James,
James Kempf wrote:
Hi Greg,
No need to go over there for comments. :-)
SEND allows the unspecified address to be used on RSs but the CGA option is
not included, so, as a practical matter, the signature can't be either since
the CGA option contains the key.
A message sent with an unspecifi
Hi Pekka,
Pekka Savola wrote:
On Wed, 2 Jun 2004, Erik Nordmark wrote:
My concern with using the unspecified address comes from the
experience we had in MAGMA where we had to specify which source
address to use in the MLDv1 packets.
RFC 3590 does allow the unspecified source for MLD messages duri
Hi Nick.
Nick 'Sharkey' Moore wrote:
On 2004-06-03, Greg Daley wrote:
RFC2461's Section 7.2.3 describes the router's own recovery from
this incorrect state, by sending subsequent router or neigbour
advertisements.
Considering that the device doing optimistic DAD which er
Hi Erik,
Erik Nordmark wrote:
If Optimistic DAD doesn't allow for unicast responses to
router solicitations, the potential for fast advertisement
to such hosts is severely diminished.
So how could something work?
I'm assuming that somehow, perhaps using a token bucket filter
instead of a fix 1 eve
G'day Sharkey,
Nick 'Sharkey' Moore wrote:
[G'day Eric, thanks for your input ...]
On 2004-06-01, Erik Nordmark wrote:
[Pekka Savola wrote:]
1) The draft specifies that instead of using a tentative address as the
source address for RS, another address or the unspecified address should be
used inste
Hi Margaret,
Margaret Wasserman wrote:
At 12:56 PM +0200 3/23/04, Jari Arkko wrote:
I think it would be possible to detect loops if we wanted really
hard to do that. That might just
lead to reinvention of the spanning tree protocol, though.
This is a danger, yes.
Why is this a danger?
I t
Hi itojun,
I think Nick was expressing frustration in this case,
rather than proposing to adopt a bad solution.
Jun-ichiro itojun Hagino wrote:
Yes, DIID probably (or something similar). I believe that simplest
solution is that a specific ID value can be allowed only for single
node on the link. A
Hi Sharkey,
Nick 'Sharkey' Moore wrote:
On 2004-02-27, Nick 'Sharkey' Moore wrote:
I'm convinced that a change needs to be made to the wording to
resolve this issue, but I'm not sure which is the better option.
My suggested text for "DAD but interoperable with DIID":
[5.4. Duplicate Address De
Hi Sharkey,
Nick 'Sharkey' Moore wrote:
On 2004-02-27, Greg Daley wrote:
Nick 'Sharkey' Moore wrote:
- When configuring a global unicast address, the link-local
address with the same suffix as that address MUST be configured
and tested for uniqueness in order to maint
Hi Francis,
Francis Dupont wrote:
In your previous mail you wrote:
>Omitting DAD altogether removes the ability to detect and correct
>address collisions, whereas optimizations such as Optimistic DAD
>mean that while there may be a short term disruption the problem
>w
Hi Francis,
Francis Dupont wrote:
In your previous mail you wrote:
> >- whether omitting/optimizing DAD is a good idea
>
> => IMHO this is the same thing, i.e., optimizing gives the same result
> than omitting.
Omitting DAD altogether removes the ability to detect and cor
Hi Ole,
Ole Troan wrote:
Greg,
This essentially the problem with DAD on wifi, right? That should
make a general solution more interesting then just a corner case.
no, this is a general problem. I've seen this on Ethernet.
I've spoken to the DAD/WIFI draft owners and we've agreed to add the
id o
ived DAD NS's are
its own.
These options would even be able to be used in non-SEND
solicitations under the constraint that there's no trust
associated with them (since they're not signed messages).
There's no further identifier definition required (although
it would be valuable
Hi Brian,
Brian Haberman wrote:
I don't like the idea of a random delay in the MLD Reports. As I
said in another note, it either adversely affects the logic in the
MLD specs or causes application delays for non-LL groups.
Is having a delay in the NS transmission alone sufficient? So that
the Rep
AD NS, the node should ensure that either there has been
sufficient time between MLD transmission and NS, in order
to guarantee packet ordering on the link.
Alternatively, explicit indication that transmission has occurred
would achieve the same purpose.
Greg Daley
is not on the
first hop, I'm pretty sure you wouldn't trust it to dictate which
address to use anyway (without further checks).
Greg Daley
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests:
Hi Jim,
Bound, Jim wrote:
>Tbis discussion should go to mipshop IMO.
>
>Of course I do not have an issue with other docs extending ND options.
>
>But I don't believe this is needed and would like to see clear what
>problem is this solving. It does not help with MD but I do not think
>this WG is
Hi Tim,
Tim Hartrick wrote:
Greg,
Backward compatability shouldn't really be a problem.
Hosts which are doing RFC2461 Router Discovery
will understand RAs with options or bits in them
indicating solicitation or completeness, but just not
be able to access the improved function.
If a host that
Hi Hesham,
Soliman Hesham wrote:
> When this problem was noted in the early days I remember
> suggesting adding
> "Solicited" bit to the router advertisement to address this
> issue. Because
> of backward compatibility problems that solution will no
> longer work well.
>
> Is there so
Hi Tim,
Tim Hartrick wrote:
All,
Suggested resolution:
- Introduce a new code (1) in the router solicitation
and advertisement. When a host sends an RS with code = 1
it requests that the RA include all prefixses valid on
that link. Similarly, when a router sends an RA with code=1
it means that
Hi Pekka,
Pekka Savola wrote:
On Tue, 4 Nov 2003, Erik Nordmark wrote:
There is really no reason to omit those prefixes that I could see.
Rather than adding new code to verify this, shouldn't we just warn about
this situation and be done with it? Or even state that prefixes SHOULD
NOT (or MUST
Dear Jinmei-san,
JINMEI Tatuya / wrote:
On Fri, 31 Oct 2003 12:52:14 +1100,
Greg Daley <[EMAIL PROTECTED]> said:
The difficulty comes when an RS comes from a global
source address which is not directly connected to
a router.
Based on RS processing rules, the host which sent
the
Hi Hesham and Pekka,
I'm not sure if this is the same issue
(looks somewhat related), but RFC2461
allows any source address for an RS message,
and only link-local response (doesn't match
scopes).
The difficulty comes when an RS comes from a global
source address which is not directly connected to
s the implementation of DHC on routers
doesn't need to be terribly sophisticated, and
avoids lumping generic configuration into
a service which is addressing and routing oriented
(Router Advertisement).
Greg Daley
IETF IPv
99 matches
Mail list logo
