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 some reason
Pekka Savola wrote:
Maybe, maybe not. Can't say for sure yet. My worry is that we're opening
up a problem we don't understand yet, one for which there basically only
-00 I-D's of.
I am glad to say that there actually is at least one -01 I-D. :-).
Movement Detection Optimization in Mobile
From: JinHyeock Choi [EMAIL PROTECTED]
There are pro and con between them. For example, if an MN receives a complete
RA which contains all the prefixes, it can form new CoA immediately. Whereas, if
it receives a RA which contains LinkID but no prefixe, an additional RS/ RA
exchange is
Markku Savela wrote There are pro and con between them. For example, if an MN receives a complete RA which contains all the prefixes, it can form new CoA immediately. Whereas, if it receives a RA which contains LinkID but no prefixe, an additional RS/ RA exchange is needed. MIP6 should not
On 2003-11-05 at 10:30, Markku Savela wrote:
MIP6 has really no need for messing with RA's. It should just detect
movement by the fact that the CoA it has been using has been removed
from the stack. Then it can find a new CoA from the stack, when it
configures.
In some cases, imminent death
This is a reminder that the last call on the deprecation document
ends today. In particular, the chairs would like to ensure that
the WG agrees on the actual deprecation text in Sections 4 6.
There has been few comments on this draft and it cannot proceed
unless the chairs can be sure that it
Sections 4 and 6 seem fine.
Minor nit in 2.2 which may cause rather than causing.
Minor nit in 3, QoS for QOS.
Also in 3, in which addresses are not ambiguous and do not have a simple
explicit scope. is maybe better left as in which addresses are not
ambiguous or maybe change to and thus do
On Wed, Nov 05, 2003 at 10:47:33AM -0800, Alain Durand wrote:
1) This is not the IETF job to mandate what an implemention choose
to support or not.
But, for example, isn't that what the node requirements draft does? Ok it
does not mandate but it uses wordage like all IPv6 nodes can be
4 Deprecation
This document formally deprecates the IPv6 site-local unicast
prefix
defined in [RFC3513], i.e. 111011 binary or FEC0::/10. The
special behavior of this prefix MUST no longer be supported in
new
implementations.
I think this section is not ready
On Wed, Nov 05, 2003 at 11:45:56AM -0800, Christian Huitema wrote:
Well, we still have link local scope, so there is still that. Do you
suggest that we write a line for each of the RFC that currently mention
site local and explain how to change them?
It would be interesting to know how many
I have no problems with the document content (and I did NOT try to read it
for editorial nits...).
--On Wednesday, November 05, 2003 13:27 -0500 Brian Haberman
[EMAIL PROTECTED] wrote:
If you have reviewed the document, have no issues with it, and agree
on its content, please let the chairs
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 understands the new
From: Erik Nordmark, October 22, 2003 1:34 PM
To: Brian Haberman
Cc: [EMAIL PROTECTED]
Subject: Re: IPv6 w.g. Last Call on Deprecating Site Local Addresses
Overall I support this document, but there are two things that have
me concerned.
1. The document talks about a replacement in
Christian Huitema wrote:
4 Deprecation
This document formally deprecates the IPv6 site-local unicast
prefix
defined in [RFC3513], i.e. 111011 binary or FEC0::/10.
I think this section is not ready yet. Couple comments:
1) This is not the IETF job to mandate what an
At 08:10 22/10/2003, Brian Haberman wrote:
This is a IPv6 working group last call for comments on advancing the
following document as an Proposed Standard:
Title : Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, B. Haberman
Filename:
Christian Huitema wrote:
Suggested text to address both comments:
The special behavior of this prefix MUST no longer be supported.
Well, we did not intend to force every implementation developer to go
fix the problem immediately, recall the products that have already
shipped, etc.
Brian,
In response to your last call, I'd like to comment on the following
sections of the document:
Section 2.4 Site is a Vague Concept
This section does overstate the case. The last paragraph itself is
sufficient cause for concern, regarding the concept as it was
envisioned. There is
Keith Moore [EMAIL PROTECTED] writes:
Or you could redirect attempts to ssh to host X so that they go to
host Y instead. This is not an inherently desirable feature.
Sure, but if I have write access to the DNS configuration (so that I
can add the SRV record), then I don't need any SRV
Keith Moore [EMAIL PROTECTED] writes:
As far as I can see, the only good reason to have the service argument
in getaddrinfo is to make it possible for getaddrinfo to perform SRV
lookups.
that's not a good reason, that's a disaster.
That's a strong word, given that the only effect on
As far as I can see, the only good reason to have the service argument
in getaddrinfo is to make it possible for getaddrinfo to perform SRV
lookups.
that's not a good reason, that's a disaster.
That's a strong word, given that the only effect on lookups in the
majority of domains
20 matches
Mail list logo
