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

List:       ipng
Subject:    (IPng 2654) Re: Last Call: Generic Packet Tunneling in IPv6 Specification ...
From:       "Conta, Alex" <AConta () Lucent ! com>
Date:       1996-12-30 23:04:45
[Download RAW message or body]

>----------
>From:
>	owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM]
>Sent: 	Monday, December 30, 1996 1:30 PM
>To: 	iesg@ietf.org
>Cc: 	ipng@sunroof.Eng.Sun.COM; dbj@CS.CMU.EDU
>Subject: 	(IPng 2651) Re: Last Call: Generic Packet Tunneling in IPv6
>Specification ...
>
>I looked over the tunnel specification document to determine
>whether the language for anycast tunnel endpoints will suit the
>needs for the mobile-IP proposal.  What mobile-IP needs is a way
>to send a packet to all the home agents (a multicast address) on
>the home network.  The ipng working group agreed to allow a
>multicast packet to be tunneled to the "Subnet router" anycast
>address, which is formed by appending zeroes to the routing prefix.

Yes Charlie. 

The agreement in the IPng working group was to make a minor modification

>to the document (Generic Packet Tunneling in IPv6) to remove the
>restriction 
>regarding anycast addresses. 

>More precisely, the agreement was to remove the excluding of anycast 
>addresses from the addresses that can be used to identify IPv6 tunnel
>exit point 
>nodes, as long as the issue with the use of such  addresses, i.e.
>fragments of a 
packet must arrive at the same node to allow a successful reassembly, is
well 
documented. 

>The tunnel specification does not specifically allow or disallow
>this behavior.  There is some cautionary wording about fragmentation
>which points out the problem that arises if a packet destined for
>an anycast address gets fragmented along the way. 
> This should not present any problem for mobile-IP.

The wording complies with the agreement in the IPng Working Group.

>However, there is one important behavior which I believe has to
>be specified.  When a tunneled packet arrives at a tunnel endpoint
>which is the "Subnet router" anycast address, the decapsulated packet
>needs to be transmitted over the correct interface(s). 

The decapsulated packet must be transmitted over the correct
interface(s) in
all cases, regardless of the type of the destination address of the
tunnel packet. 

> Specifically,
>the decapsulated packet needs to go out over each interface which
>correspond to the routing prefix forming the "Subnet router"
>anycast address. 

Perhaps I misunderstand what you mean here - you seem to imply that the
tunnel packet destination address information ("anycast address") is
used for 
forwarding  the original packet resulting from decapsulation ("all
interfaces"). 
This is not correct.

For clarification: 

There is no implied relationship between the tunnel packet destination
address,
and where the resulting original packet is being forwarded after
decapsulation. 

The text in the specifications says:

     "Upon receiving an IPv6 packet destined to an IPv6 address of a
tunnel
   exit-point   node,  its  IPv6  protocol  layer  processes  the tunnel
   headers. The strict  left-to-right  processing  rules  for  extension
   headers is applied. When processing is complete, control is handed to
   the next protocol engine, which is  identified  by  the  Next  Header
   field  value in the last header processed. If this is set to a tunnel
   protocol value,  the  tunnel  protocol  engine  discards  the  tunnel
   headers  and  passes the resulting original packet to the Internet or
   lower layer protocol identified by that value for further processing.
   For  example,  in  the case the Next Header field has the IPv6 Tunnel
   Protocol value, the resulting original packet is passed to  the  IPv6
   protocol layer."

The original packet resulting from decapsulation is forwarded according
to 
the destination address specified in the original IPv6 header. If the
destination 
address is that of the processing node, the packet is consumed by the
node. 
If not, the packet is transmitted  to the appropriate next hop router,
if the hop limit 
decremented by one is a non-zero value (if is zero the packet is
discarded).

In your specific case, the original packet destination address is a
multicast address,
and that is the address the original packet (after decapsulation) is
forwarded too.

> And, when the (decapsulated) hop-limit is 1, the
>decapsulated packet must ONLY go out on interfaces which correspond
>to that routing prefix. 

It seems to me that there is an assumption made in the above statement
that 
tunneling gives more meaning  to the Hop Limit.  The IPv6 tunneling does
not 
apply any additional meaning to the Hop Limit. According to the IPv6
packet 
forwarding rules, original packets (decapsulated) that have the  hop
limit 1 before
forwarding, are discarded if they must be forwarded to another node -
because the 
Hop Limit is decremented to zero (0).

>More generally, going out a different
>interface of the same "Subnet router" would count as an additional
>hop (and the hop-limit decremented and handled accordingly).
>Moreover, in the case when decapsulation yields a multicast packet,
>the packet must go out over ALL such appropriate interfaces which
>correspond to the routing prefix, for which there are members
>of the multicast group.

Yes.

>I think it is arguable that the abovementioned behavior is implicit
>in the supposed handling for the "Subnet router" anycast address.
>However, perhaps it is better to be sure that implementors do the
>right thing, by spelling it out in detail somewhere within the
>tunneling specification.

The IPv6 forwarding rules are clearly specified by RFC1883. Duplicating 
information from other RFCs in the tunneling document was, as a general 
rule, avoided. I thought that the reference to the forwarding rules in 
RFC 1883 was made obvious enough without going to extremes.

>As an unrelated and terribly minor matter, I suggest that in the
>second sentences in both sections 7.1 and 7.2 it is clarified that
>procedures (a) and (b) of both sections are meant to apply only
>to packets which are too big for the tunnel.  That could be
>achieved by adding the single word "such", as follows:

>	The  fragmentation  of such tunnel packets containing
>   IPv{6,4} original packets is performed as follows:

I am sensitive to text readability improvements. Thanks for the
suggestion.

Thank you,
Alex
>
------------------------------------------------------------------------------
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]