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

List:       ipng
Subject:    (IPng 2663) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ...
From:       Charlie Perkins <charliep () watson ! ibm ! com>
Date:       1996-12-31 18:32:56
[Download RAW message or body]

The following clarification is necessary after my note
yesterday about using an anycast tunnel destination.

===============  Discontiguous subnets ===============

When I wrote the note, I was under the possibly erroneous
impression that discontiguous subnets were allowable in IPv6.
This explains my attempt to be careful, and to request that
a decapsulated packet be sent out over "all interfaces" that
match a routing prefix.  This will never be necessary if
there are no discontiguous subnets.

=========================================================

Moreover, what I tried to do was to frame the specific
requirement for mobile IP in a way that was able to be
generalized in the future, as the ways that tunnels might
be used for encapsulating multicast packets become better
understood.  I think it is fair to say right now that issues
remain.

The specific requirement for mobile IP is as follows.
We need to deliver a multicast packet to all home agents
on a home network.  That packet should not go to any
other networks.  Let's assume for now that the home network
is contiguous, so that any multicast packet issued from
any interface on the home network will reach all the
multicast group members on the home network.

Suppose we tunnel the multicast packet, using the "Subnet routers"
anycast address as the tunnel destination.  I think we can
assume that such a tunneled multicast packet would often
(usually?) be received by a router in the anycast group, but
from an interface not on the home network.  I wanted to make
the following model:
	1) When decapsulating, the inner packet "seems" as
	   if it were received from the interface on the
	   home network, since it was delivered to a
	   destination address on the home network.  In other
	   words, the inner packet does NOT "seem" as if it
	   was received from the same interface as the
	   encapsulated packet was received from.
	2) Given (1), if a multicast address is the
	   destination of the inner packet, and the multicast
	   packet was sent with (hop limit == 1), then
	   the multicast packet CANNOT be "forwarded"
	   across the router to be issued from any other
	   interface that does not reside on the home
	   network.

I think that the above model is reasonable and conforms to
a consistent analysis of what encapsulation might be supposed
to provide.  I also think that it's the best interpretation
for controlling the hop limit.

In the particular case of mobile IP, it is important that
the packet addressed to "all home agents" be sent out _ONLY_
on the designated home network.  If the router were connected
to different networks, each with home agents serving different
populations of mobile nodes, unexpected responses might occur.

==================================================================

I hope my proposal for handling hop limits in such a way to
tightly control distribution of mobile IP multicast packets
to the home network is considered acceptable.  It has the
virtue of fitting nicely in a generalizable framework for
handling other kinds of encapsulated packets with (hop limit == 1)
sent to the "Subnet routers" anycast address.  Otherwise, I
am open to suggestion.

As a last resort, we could be very, very particular to specify
a unique behavior in the case when a packet is tunneled to the
"Subnet routers" anycast address.  The router would be expected to
decapsulate that packet, and then perform the following algorithm:
	1) If the address is "all home agents", and
	2) If the protocol is UDP, and
	3) If the port is 434, then
	4) Then, send the packet out to the home network
	   associated with the anycast "Subnet routers" address.

I thought that it would be better to frame the processing as
consistent with somewhat more general handling of encapsulated
multicast packets, but I am quite willing to go along with
the collective wisdom of the working group in this matter.

In order to be as clear as possible about handling the hop
limit, I should express my current understanding of how such
a hop limit is supposed to be handled during tunneling.
Say that a process on the mobile node wishes to send a
multicast packet to home agents on its home network.  Then
	1) The packet is built, specifying hop limit == 1.
	2) The multicast packet is encapsulated, causing
	   the hop limit to be decremented to zero.
	3) The encapsulated packet is transmitted, and
	   the hop limit of the inner packet remains zero
	   until it arrives at the tunnel endpoint.
	4) The decapsulator unwraps the inner multicast
	   packet, and sends it out from the proper
	   interface (still with hop limit == 0).
	5) No forwarding of the multicast packet can occur.

In the context of the above understanding on my part, I quote
from Alex's (reformatted) note, and ask for further elaboration
in light of the needs I have detailed earlier in this (long)
note.
========================================================================
>>>  ==  me
>>   ==  Tom
>    ==  Alex

Message-Id: <c=US%a=_%p=Lucent_Technolog%l=SNOOPY-961231001858Z-452@snoopy.agile.com>
From: "Conta, Alex" <AConta@Lucent.com>
To: "'Charlie Perkins'" <charliep@watson.ibm.com>,
    "'owner-ipng@sunroof.Eng.Sun.COM'" <owner-ipng@sunroof.Eng.Sun.COM>
Cc: "'iesg@ietf.org'" <iesg@ietf.org>,
    "'ipng@sunroof.Eng.Sun.COM'" <ipng@sunroof.Eng.Sun.COM>,
Subject: (IPng 2655) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ... 
Date: Mon, 30 Dec 1996 19:18:58 -0500

>>> And, when the (decapsulated) hop-limit is 1, the
>>> decapsulated packet must ONLY go out on interfaces which correspond
>>> to that routing prefix.
>
>> The packet should only go out the interface on which it was
>> recieved. It should not go out multiple interfaces. That could cause
>> replication of packets.
> 
> I think the original packet resulting from decapsulation may go out on 
> any of the interfaces of the tunnel exit point node, and may go out on
> multiple interfaces. The interface is chosen based on the information
> carried by the original packet headers - main, and routing extension header.
> The main header, and routing header in the original packet are both
> processed according to RFC 1883. If the destination address is a multicast
> address, and multicast routing is enabled, than the original packet is
> forwarded on those interfaces on which there are downstream group members
> - careful here to not send the packet back on the link it came on.

The problem I have with this is that there are likely to be group
members for the "all home agents" multicast address on each network
attached to the anycast recipient, and yet only one home network
should be selected for dissemination (when hop limit == 1).
In fact, I'm not even sure it's relevant which interface the
encapsulated packet arrived on.  The combination of the anycast
destination and the hop limit are the relevant factors here, and
seemingly in other cases involving such tunneling operations.

Regards,
Charlie P.
------------------------------------------------------------------------------
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]