Erik Nordmark writes:
I don't think stable addresses per se is the key
thing - it is the robustness of the communication
that is important.
I agree with this. However, the minimal degree of robustness
is working at all - something which requires some address of
some sort. There
Vijay,
I think the issue isn't whether this particular optimization is important or
not. The issue is whether we should leave it in the base spec or put it into a
spec with all the other ND optimization bits.
jak
- Original Message -
From: Vijay Devarapalli [EMAIL PROTECTED]
On Tue, Nov 19, 2002 at 04:57:25AM +0200, Pekka Savola wrote:
On Tue, 19 Nov 2002 [EMAIL PROTECTED] wrote:
i think MAY is fine.
Agree.
conditions where the spec is appropriate
are spelled out enough in RFC3041.
Actually, they definitely *aren't* (or rather, they give a
I am particularly concerned that we have a Mobile IPv6 specification
that, when implemented, gives sensible results. Eliminating the possibility
for having faster router advertisements does not give sensible results.
I don't want to eliminate it - I want to make it better.
But the fear of
On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote:
We have always been told that stable global v6 addresses will not be available
to end users, or at least will not be available to end users at a low cost.
Told by who? I can see ISPs wanting to charge for extra services where they
So, perhaps my comment is a bit naive, but as the changes have been
discussed in the MIP WG and many people think the changes are
sane in the IPv6 WG ... I wonder what would be accomplished by
breaking them out in a seperate document. Since the IPv6
WG will be working updating ND, could not
Charlie,
I am particularly concerned that we have a Mobile IPv6 specification
that, when implemented, gives sensible results. Eliminating the possibility
for having faster router advertisements does not give sensible
results.
Noone is arguing that the possibility for having faster RA should
Missed my point. You can't implement part of ND for a feature like MIPv6.
You have to understand ND as a software engineer.
Understood. But there are different boxes that need to implement different
things.
Home agents need to implement the 'H' bit in the RA and the 'R' bit in
the prefix
Hi James,
The primary issue is whether the ND spec itself should benefit.
I agree. I think it should. My suggestion is that MIPv6 discusses
what is needed for MIPv6 (maybe even moved into an appendix) and
this data is taken as a starting point for updating 2461.
The behavior of DAD
Hello Erik,
No one should fear making the technology better.
However, having a specification that gives sensible
results does not in any way impede that effort.
If Mobile IPv6 specifies something, that something
can be taken in to account in any future specification.
I can't see how it would
Hello Thomas,
You seem to be concerned that if we change this value in
the base Mobile IPv6 specification, then suddenly it won't
make as much sense to change it or otherwise specify it
in a future ND document. I think that it patently untrue.
So, I strongly believe that we can have a good base
Erik,
What you bring up hard rate limit vs token bucket filter and the like
are optimizations not brokeness in MIPv6 and so is the idea of a
separate spec. We can always optimize and continue to optimize etc.
Leaving it in the current spec does not remove the potential for
optimization. Taking
And the key thing in my opinion is that the (access) routers
need to implement the faster RA and the advertisement
interval option. Thus the folks that implement routers need
to implement all of ND (as software engineers) but they
probably don't need all of the MIPv6 extensions to ND.
I
On Tue, 19 Nov 2002 [EMAIL PROTECTED] wrote:
By burying the solution for this into the MIP spec, it
removes the possibility that wider IPv6 nodes can benefit.
I don't think we should bury it in the MIP spec, but first
address it in the MIPv6 spec then take that move it into a
2461-bis
I agree with this. However, the minimal degree of robustness is working
at all - something which requires some address of some sort. There
needs to be a way to get an address when you don't have a provider.
This means either scoped addresses as we have defined them already (and
in
conditions where the spec is appropriate
are spelled out enough in RFC3041.
Actually, they definitely *aren't* (or rather, they give a wrong
impression), see draft-dupont-ipv6-rfc3041harmful-01.txt -- new security
considerations / applicability consideration is needed.
I agree with
I'm reluctant to reach any conclusion about this until
we have complete clarity about the flow label, which as
we concluded yesterday still needs more work. So I think
that the current (ambiguous) text is probably OK for now.
I'm afraid it will need revisiting at some time in the future.
Leaving it in the current spec does not remove the potential for
optimization.
Doing local optimizations to a specification which is 150 pages might be
possible yet it is painful.
Taking it out may cause MIPv6 to not ship.
Making the RFC not ship? Or making something else not ship?
The
Hello
I belive that some ND changes have to remain in the MIPv6
spec. The ND changes without which the base MIPv6 spec is
incomplete and can not be made to work well should remain in the
spec. An example of this is RA timers. Without faster
RAs, the movement detection algorithm takes way to
In your previous mail you wrote:
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt
I just want to point out that Francis and Vlad in the above both are
implemetors ...
= as my name occurs in this thread where my opinion is nicely represented
by Erik, I often
Jim,
if you read my mail again, it was specifically a reply to Pekka.
he called the changes arbitrary. that was really wrong.
Vijay
James Kempf wrote:
Vijay,
I think the issue isn't whether this particular optimization is important or
not. The issue is whether we should leave it in the
Erik Nordmark [EMAIL PROTECTED] wrote:
|Being the probable guilty party for introducing this thought back in
|draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective.
|
|I don't think stable addresses per se is the key thing - it is
|the robustness of the communication
Francis,
Francis Dupont wrote:
In your previous mail you wrote:
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt
I just want to point out that Francis and Vlad in the above both are
implemetors ...
= as my name occurs in this thread where my opinion is
Hesham Soliman (EAB) wrote:
I'm getting very confused when reading this
discussion. Some people are focusing on the
RA intervals, others about DAD (2462) and
others talk generally about ND.
Please divide the issues...
AFAIK we have the following (independent) issues:
- RA intervals
I'm trying to summarize the discussion about the constants. First
I'd like to agree with Hesham: We need to treat the constants,
optimistic DAD, collision detection all as separate items. What I
see is that on most of the issues we are close to consensus, e.g.
I don't think anyone is against
On Tue, 19 Nov 2002, Vijay Devarapalli wrote:
- RA intervals were reduced by MIPv6 (changing 2461)
- When DAD fails we configure a new address and try again (2462)
- Elimination of DAD delays (optimistic DAD)
- Eliminsation of the random delay before sending an RA (fast RA)
The last
In your previous mail you wrote:
MIPv6 does not say router should send RAs more frequently. it
just says access routers SHOULD be configurable to send RAs
more frequently.
= We know this is translated in many minds in the first statement...
And this doesn't change the argument that
I agree with Hesham. I think there is a lot of difference between RA interval
changes that have been in the MIPv6 draft a long time and Fast RAs that has
known failure modes that need to be experimented with to determine their
significance.
I'd add the minor points that section 11.5.2
I think, but I'm not certain, that most of the large sites
that do this have completely different DNS content in the
two-faces i.e. it is more like two separate DNS services than
two-faces of the same DNS database. That is, the DNS outside
the firewall contain a subset of the RRs and
Yes, needless complexity is bad. But site-locals don't add any
significant complexity to applications (which I think I've demonstated
enough in too many emails already).
this is only true if globals are always available to any node that
potentially participates in an application that
- RA intervals were reduced by MIPv6 (changing 2461)
- When DAD fails we configure a new address and try again (2462)
- Elimination of DAD delays (optimistic DAD)
- Eliminsation of the random delay before sending an RA
(fast RA)
The last two bullets are addressed in
On Tue, 19 Nov 2002, Hesham Soliman (EAB) wrote:
= Why do you disagree with 2? Do you think a MN
should disable an interface when DAD fails the
first time?
Sounds disastrous
I don't disagree with the problem (but perhaps with how you treat it), but
let me say it again:
*THERE'S NOTHING
I don't disagree with the problem (but perhaps with how you
treat it), but
let me say it again:
*THERE'S NOTHING MIPV6-SPECIFIC IN THAT*
= Mobility will increase the minute probability of
collision. Anyway, that's not the point, you're saying
that you disagree with the
Hi Jim,
There needs to be a way to get an address when you don't
have a provider. This means either scoped addresses as we
have defined them already (and in multi-link locations, this
means either site-local or multi-link subnet routers and
link-local), or some sort of
Yes, needless complexity is bad. But site-locals don't add any
significant complexity to applications (which I think I've
demonstated
enough in too many emails already).
this is only true if globals are always available to any node
that potentially participates in an application
Richard Draves writes:
Yes, needless complexity is bad. But site-locals don't add any
significant complexity to applications (which I think I've
demonstated
enough in too many emails already).
this is only true if globals are always available to any node
that
I find this kind of thinking rather suspect. The
question in my mind shouldn't be why global, but
why not global. There seems to an underlying
assumption that site locals would give better
security properties due to their global
inaccessibility. I find that rather uncompelling
and
I think the vendor of one of
these devices should have the freedom to determine the
device's out
of the box configuration, based on expected usage patterns.
Here I strongly disagree. It's simply not reasonable in
general for a vendor to make assumptions about the
distribution of
On Tue, Nov 19, 2002 at 10:37:33AM -0800, Richard Nelson wrote:
I'd add the minor points that section 11.5.2 contains
a basic version of optimistic
DAD (its been there since draft 12) [...]
Basic? ... Very Basic!
Furthermore, the mobile node MAY continue using the
address
Richard wrote :
I'd add the minor points that section 11.5.2 contains a basic version of optimistic
DAD (its been there since draft 12) and that there AP cached RAs are an
alternative to fast RAs in yet another separate draft.
I agree with Richard.
The AP cahed RAs can be esaily
40 matches
Mail list logo
