At 4:32 PM -0400 5/24/00, Bill Sommerfeld wrote:
> > If you really need to receive both addresses for some reason, the care-of
> > address is the one that should be obtainable only via IPV6_RECVDSTOPTS.
> > Logically, the IP layer in the correspondent host should swap the received
> > home address and care-of address before passing the packet to an upper
> > layer.
>
>This sort of thing gives us security types hives..

Yeah, it gives even us aesthetically-sensitive, non-security types hives.

The architecturally clean way to do what Mobile IPv6 does would be
for the mobile host to generate an IPv6 packet with source = home addr,
dest = correspondent addr, and then encapsulate that in another
IPv6 header with source = care-of addr, dest = correspondent addr,
in order to get it past the ingress filters at the foreign site.
Just another example of tunneling.  If it were done that way, the
PMTU discovery issue I parenthetically mentioned earlier would become a
non-issue (we already know how to make PMTU discovery work through tunnels),
and at the receiving correspondent host, the outer header would stripped
off (normal tunnel endpoint decapsulation) and the original packet with
the home address as source would be delivered to the receiving upper layer.

I presume the Mobile IP WG decided to do it differently to avoid the
overhead of a full encapsulating header.  But perhaps we can think of the
required process as doing an encapsulation, as described above, and then
performing a weird, mobile-IP-specific type of header compression (inserting
an option, moving some addresses, discarding the outer header) at the
sender, and then reversing the process at the receiver.  Does that help?
I didn't think so.

Steve

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to