Keith,
The lack of global routability of site-local addresses is a
feature,
not a bug.
I don't think we have concensus on that. there seem to be at
least a few people who want PI addresses that *are*
routable, or at least, for which such restrictions are not imposed.
I am just
Tony,
Michael Thomas wrote:
So I have a question for those who support
connected site locals: what would prevent a new
RFC from updating Brian's wording for site locals
(if that's the right thing)?
I say this because it seems to me that there's a
lot of issues being conflated
Mohan Parthasarathy wrote:
...
I miss something here. How do you make sure that nodes
configure just site local and not global address on seeing an
RA ? Are you keeping them in separate networks i.e not mixing
nodes that require globals and site locals ? If so, then I
can do
Personally, I don't have a big problem with the suggestion
itself, but I do not agree with it, simply because it's a
meaningless restriction. I'd rather see a
separate BCP for this, or at least say should not and
explain why.
I agree with Hesham here. Should we not explain why we
Title: RE: IPv6 MTU for tunnel pseudo interfaces
At a minimum, implementations should be able to convert the=20 ICMP
errors happening from within the IPv4 tunnel back to ICMPV6
error and
send it back to the original sender (IPv6 sender in case of
IPv6 over
IPv4
Title: RE: [mobile-ip] Re: HAO and BE processing will be mandated
Vijay,
I am missing something. Can we invent a new option in the future
and call it a MUST be processed by all nodes ? If a node does
not understand the option, it should use the icmp parameter
problem to return errors.
be all the details (there is
quite a bit of them) are not coming together in one piece. May be the promised
draft might clear this up I guess.
-mohan
-Original Message-
From: Hesham Soliman (ERA) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 04, 2002 12:29 AM
To: Mohan
Title: RE: Allocating a bit in the RFC2374 Interface Identifier
Brian and Pekka,
I am tired, and probably the situation is more complex,
but this my initial
reaction. It looks like in the scenario you describe
Alice and Bob
would end up running different
Title: RE: Allocating a bit in the RFC2374 Interface Identifier
Or am I missing something?
Pekka,
Perhaps the question was about the whole address and not just
the interface ID. You've described how the interface ID is
crypgraphically tied to a
public key.
But
(ERA)
Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander;
[EMAIL PROTECTED]; Erik Nordmark
Subject: RE: Allocating a bit in the RFC2374 Interface Identifier
On Fri, 22 Mar 2002, Hesham Soliman (ERA) wrote:
= For all those opposing the addition of the bit
in the IID, I really
Title: RE: Allocating a bit in the RFC2374 Interface Identifier
Mohan Parthasarathy wrote:
t very clear as to why you have to reserve a bit in the address to
express different security mechanisms being used. Why can't this be
built into the protocol itself
5) There is no route for this IPv4 packet [which is actually an ICMPv6
error] as determined by the IPv4 routing table. An ICMPv4 error is
generated.
6) The ICMPv4 error is converted to an ICMPv6 error so that it can
be sent to the original IPv6 sender [router itself].
Hi,
I am sending to both the lists as it may be relevant.
It seems that forwarding packets between two tunnels (either IPv4
over IPv4 or IPv6 over IPv6 or IPv6 over IPv4 tunnels ) can cause
unneeded exchange of packets till the ttl becomes zero. Following
is the sequence and wondering whether
Francis,
In section 4, you tried giving names to the various option
headers and i think it can be a bit more clearer. How about
the following :
1) The option header before routing header (called as
destination options (1) in rfc2460) can be called
as routing option header as this appears
In your previous mail you wrote:
The question has to do with NA NS where the destination address (== the
target address) is tentative.
= I have an incredibly simple answer: our code doesn't receive packets
to a tentative address!
Ideally one should not recieve packets
I have a different question in the same context. Assume two nodes
node A and node B on the same link. If node A (malicious) does
not do *DAD* and sends out a packet with node B's address as source
address to B, B should drop the packet. But this is not mentioned
in the spec anywhere. It
16 matches
Mail list logo
