[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 2411) Warts with topology dependent ID
From:       Masataka Ohta <mohta () necom830 ! hpcl ! titech ! ac ! jp>
Date:       1996-10-30 11:44:08
[Download RAW message or body]

Brian;

> > > When you move within or outof the site, don't you think it good if
! > > a home agent just rewrite the locator part of packets and not
> > > to tunnel?

> I can't parse this even with the correction. Can you explain
> in more detail please?

Sure.

If a home agent can rewrite the locator part of the destination
address of a packet to mobile host WITHOUT AFFECTING the *ID part,
no special treatment, such as tunneling or mandatory addition of
a routing header, is necessary.

I personally communicated with Charlie and now know that his
second proposal at Stockholm is to use a routing header.

Yes, the encapsulation method is a quite serious issue of mobility.

Note that, locator part shouldn't be protected by psuedo header
check sum of TCP nor authentication header of IPSEC and it's
still secure becasue the only possible attack of intermediate
routers (including home agent) modifying the locator is just a
denial of service and the routers can always deny service by
simply not forwarding packets.

BTW, topology independent *ID in IPv6 address is also good to
retain regular subnet model even for the communication between
a foreign agent and the mobile host.

Kre, are these the warts you want to remove?

Finally, though the statement might activate an automatic SPAM
detector :-), it's absolutely free!

We only have to convince people (if any) who, IMO unfoundedly,
think 64 bits are not enough to locate a subnet.

Are there any?

						Masataka Ohta
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          	      http://playground.sun.com/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]