Dear All
I wanted to know about scenario of "Neighbor
Discovery over Tunnels"for bi directional configured tunnel?
In which circumstances router will send NS packect
(Required or not )and wait for Ack to come again in Reachable state?
Bcoz ipv4 router should not send any NS
packet.
Posting only as an interested individual:
Me to.
- What level of impact, if any, will the widespread
use of site-local addresses have on:
- Applications (current and future)
- Transport Protocols
-
It should be possible for a mobile node to use a site-local prefix as long
as it only ever roams within the site. This seems to go along with the
proposal that site-local prefixes should only be used in domains that are
disconnected from the Internet. If a mobile node has a global home
to me it seems completely unreasonable for any device to make
any assuumptions about the trust level placed in site-local
addresses. this should be a MUST NOT.
IETF IPng Working Group Mailing List
IPng Home Page:
I was suggesting that SL is an indication that a filtering policy has
been applied to this network.
seems like a *huge* stretch - several of the ideas for using SL have nothing
to do with filtering. also, SL strikes me as an extremely poor mechanism
for communicating filtering policy.
in
there's a set of cases where the MN uses Localized mobility management
such as HMIPv6 and can use only site locals within a set of access
networks.
I'm not sure if this is complete, but I don't see it's that
problematic.
Which problem are you trying to solve here to which the solution
is
Erik Nordmark wrote:
It should be possible for a mobile node to use a site-local
prefix as
long as it only ever roams within the site. This seems to go along
with the proposal that site-local prefixes should only be used in
domains that are disconnected from the Internet. If a
Hi Erik,
there's a set of cases where the MN uses Localized mobility management
such as HMIPv6 and can use only site locals within a set of access
networks.
The MN is reachable through a regional care-of-address which is
globally scoped. In this case, communication within the access network
Keith Moore wrote:
I was suggesting that SL is an indication that a filtering
policy has
been applied to this network.
seems like a *huge* stretch - several of the ideas for using
SL have nothing to do with filtering. also, SL strikes me as
an extremely poor mechanism for
Kieth Moore wrote:
to me it seems completely unreasonable for any device to make
any assuumptions about the trust level placed in site-local
addresses. this should be a MUST NOT.
Why do you keep insisting that lack of public accessability implies
anything about trust?
Tony
It doesn't matter how many times you write this, you can not make it
become true. Brian keeps pointing out the simple case of an
intermittently connected network getting a different prefix on each
connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR
APPLICATION REASON TO HAVE
Attached is a proposed update to the IPv6 working group charter. This will
be discussed at the IPv6 session tonight at IETF55 and on the mailing list.
Please comment on the list and at tonights session.
Bob Hinden and Margaret Wasserman
IPv6 chairsInternet Protocol Version 6 (IPv6) Working
Unless I've missed something, I've not received any responses to the
attached message. I interpreted the silence as a sign that there is
no need to update 2292bis wrt the issues in this thread. Otherwise,
please let me know.
Thanks,
JINMEI, Tatuya
I was suggesting that SL is an indication that a filtering
policy has
been applied to this network.
seems like a *huge* stretch - several of the ideas for using
SL have nothing to do with filtering. also, SL strikes me as
an extremely poor mechanism for communicating filtering
So let's not loose sight of the fact that the goal is a robust network.
well said. and offhand I don't see any reason to assume that SL addresses
are more stable/robust than globals.
IETF IPng Working Group Mailing List
IPng
I think these are just editorial nits.
The draft talks about commercial but I think the same issues are present
if there is a non-commercial ISP that wants to offer non-commercial IPv6
service. So in terms of describing the need for the technology it is probably
best to drop the commercial
From: Erik Nordmark [EMAIL PROTECTED]
Subject: Comments on prefix delegation requirements
Date: Tue, 19 Nov 2002 02:46:24 +0100 (CET)
I think these are just editorial nits.
The draft talks about commercial but I think the same issues are present
if there is a non-commercial ISP that wants
On Tue, 19 Nov 2002, Pekka Savola wrote:
Hello,
FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
making all of these assumptions to e.g. Neighbor Discovery timer values.
s/assumptions/arbitrary changes/
shouldn't be writing quickly under sporadic network
On Tue, 19 Nov 2002, Erik Nordmark wrote:
The draft talks about commercial but I think the same issues are present
if there is a non-commercial ISP that wants to offer non-commercial IPv6
service. So in terms of describing the need for the technology it is probably
best to drop the commercial
i think MAY is fine. conditions where the spec is appropriate
are spelled out enough in RFC3041.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
making all of these assumptions to e.g. Neighbor Discovery timer values.
I think this makes sense as well. Let me try to state my reasons.
Even though I think the current ND changes in the MIPv6 spec make sense,
I'm
Please remove the following paragraph from page 5:
With [RSVP] or [SDP] either the source or the destination of the flow
could have a preference for the Flow Label value to be used. For
example, a destination with multiple sources sending packets to it
could require all the sources to
The engineers who implemented MIPv6 and there are a few and in the MIPv6
working group are same engineers that do ND in most cases today. The
issue is not one of expertise. This is MIPv6 work not IPv6 work.
/jim
[Honor, Commitment, Integrity]
-Original Message-
From: Pekka Savola
Erik,
Come on. You can't implement or understand MIPv6 if you don't have ND
down. It is not even possible.
The engineers in MIPv6 are clearly qualified to work to enhance ND.
I don't believe moving it to separate spec will make it more
implementable at all. MIPv6 is no longer a MUST.
All
Come on. You can't implement or understand MIPv6 if you don't have ND down.
It is not even possible.
The engineers in MIPv6 are clearly qualified to work to enhance ND.
I think I can implement MIPv6 just fine without section 7.5, 7.6, and 7.7
in the MIPv6 draft. After all, I'll have 149-3
Pekka Savola wrote:
FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
making all of these assumptions to e.g. Neighbor Discovery timer values.
s/assumptions/arbitrary changes/
on the contrary, they have been well thought out and discussed
on the MIPv6 mailing
On Mon, 18 Nov 2002, Vijay Devarapalli wrote:
FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
making all of these assumptions to e.g. Neighbor Discovery timer values.
s/assumptions/arbitrary changes/
on the contrary, they have been well thought out and
Hi Erik,
So while I don't want to slow down the MIPv6 specification or the
implementation and deployment, I think breaking out these pieces will help
with specification and protocol modularity, which makes it easier and quicker
to revise the specifications along the standards track etc.
So,
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 that is
Hello Erik,
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.
However, the stated reasons for wanting to change the existing
Dear Keith n all
Please clear my doubt. How these
following lines of RFC's are possible?
If an implementation provides
bidirectional configured tunnels it MUST at least
accept and respond to the probe packets used by Neighbor Unreachability Detection. Such implementations SHOULD
also
Erik,
Come on. You can't implement or understand MIPv6 if you
don't have ND
down. It is not even possible. The engineers in MIPv6 are clearly
qualified to work to enhance ND.
I think I can implement MIPv6 just fine without section 7.5,
7.6, and 7.7 in the MIPv6 draft. After all,
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 not rubber neckers and both work in IPv6 WG and MIPv6 WG so
the expertise is in both groups (Thomas this is one example why I think
IPv6 WG is
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
needs to be a
34 matches
Mail list logo
