On one hand I agree with Erik that new types are better than overloading the
semantics unnecessarily. The basic problem I am having with this thread is
understanding the problem it is trying to solve. Since the HA is required to
be in all possible routing paths to my home subnet (else some parts of the
world will never contact the node when it is mobile), it has to be a
function of the last hop router. The premise of this proposal was that the
MN would need to ask the HA for a prefix so it could configure its home
address. Since it knows (presumably via configuration) the address of the
HA, (and given the HA has to be in the routing path) it already has a
useable prefix. I have always assumed that the MN is configured with its
home prefix, then it would use the all-routers anycast address to find the
HA. In this case the proposed messages are unnecessary. Clearly I need a
picture to understand why the MN would know its HA, but not its home prefix.
Tony
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Erik Nordmark
Sent: Monday, March 05, 2001 1:52 AM
To: T.J. Kniveton
Cc: Erik Nordmark; Mattias Pettersson; Powell, Ken;
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: New idea for Router Sol/Adv and Mobility - NO new types
> >> 1. The TTL of RS is < 255, which tells the HA it is from off-link.
> >
> > Or a spoofed RS. When a router receives a spoofed RS it would presumbly
> > log an event and/or increase a counter.
> > With your overloading proposal it can't tell the difference
> > between a spoofed one and a mobile node using an RA.
>
> Enlighten me, how exactly does creating a new message type solve this
> problem? It seems to me that it just shifts it to a different ICMP #.
It doesn't make the spooing issue go away (I didn't claim it did)
but allows the current rules for the current ICMP types to stay unchanged
including any logging of ttl < 255 packets.
The new message types need to have rules that deal with spoofing one
way or another. But this might e.g. be to mandate some IP level security
mechanism for all messages having the new types.
Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
