Subject: Question about Routing Headers

From: Lori Napoli <[email-masked]>
Date: Mon, 19 Apr 2004 15:28:39 -0400

I have a question about Routing Headers (type 0), more specifically what 
happens when we receive an ICMPv6 msg where the offending packet contained 
a routing header.  From RFC 3542,  a routing header can contain 127 IPv6 
next hop addresses.  Therefore, if a packet specified the maximum number 
of entries in a routing header, the routing header alone would exceed 1280 
bytes.   Now, if an intermediate node needed to drop this packet and 
generate an ICMPv6 msg,  the ICMPv6 msg can only contain as much of the 
offending packet as will fit within minimum MTU (1280 bytes).  Therefore 
it is possible for the offending packet within the ICMPv6 msg to not 
contain the entire routing header.  This ICMPv6 msg will be sent to the 
original source of the packet, but the source address of the ICMPv6 msg 
will not be the original destination address of the packet since the 
destination address in the IPv6 header changes when there is a routing 
header.  So, how does the originating node correlate this ICMPv6 packet 
with the correct socket?  Since we can't rely on the entire routing header 
being present in the offending packet, we can't even rebuild what the 
original destination would have been.

My second question is that for IPv6, the Type 0 Routing header can contain 
127 addresses.  This routing header is considered non-fragmentable.  If 
your interface is Ethernet with a standard 1492 MTU, this packet cannot be 
sent on that interface since the routing header alone would exceed 1492. 
It seems inconsistent to me to allow such a large non-fragmentable header. 

Lori
e-mail: [email-masked]

---

From: "Tarun Kr. Sharma" <[email-masked]>
Date: Tue, 20 Apr 2004 09:52:34 +0200

Hi,
First of all sorry for asking non relevent question but somehow it belongs to
IP. So hopefully I will get a reply for this question.
Actually long back when I just started the work on IP then i came across one
problem. As for my company we have IP addresses in our LAN and we have one entry
for default IP address which is used if our destination IP address doesnt match
with anyone in our ARP cache. Now router decides whether this IP address belongs
to outer world or not based upon its net address and routes it accordingly.
Now the question was if the source IP address remains same as my host address in
LAN or it is replaced by router's IP address. If it remains the same then it
gives a logical picture and packet can travel from destination to source(reverse
path). But if it is replaced by router's address then how can packets come to
source address. According to my understanding source IP address doesnt change
and it works in a unique fashion. But it this is the case then why we give only
one IP address to corporates. We give it because we dont want to use so many
IP addresses for a corporate and IP addresses are limited.
Even this is one of the reason we are going towards IPv6.

Please give me some clear picture of this.
Thanks and excuse me of non relevent question. But this is the place where I can
get best answer.

Regards
Tarun Sharma

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 22 Apr 2004 15:00:01 +0900

>>>>> On Tue, 20 Apr 2004 09:52:34 +0200, 
>>>>> "Tarun Kr. Sharma" <[email-masked]>, Tarun_KUMAR/BE/[email-masked] said:

> IP. So hopefully I will get a reply for this question.

You seem to ask how NATs work and complain about how NATs are
bad...I'm afraid this list is not the appropriate place to bring such
a thing to.  (Of course, someone in the list may have the answer to
the question, but I guess this is the reason for the silence so far).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 22 Apr 2004 15:28:45 +0900

>>>>> On Mon, 19 Apr 2004 15:28:39 -0400, 
>>>>> Lori Napoli <[email-masked]> said:

> next hop addresses.

I first would like to note that the RFC3542 specification is not the
essential part of this discussion.  RFC3542 simply allows the maximum
number based on the protocol specification, and this is rather a
protocol issue.

> Therefore, if a packet specified the maximum number 

I think your concern is valid, but this is mostly not specific to
routing headers.  If we want to deliver an ICMPv6 error to a
particular socket(s), the inner packet of the error message should
contain the upper layer header such as a TCP header.  However, we
cannot always guarantee this due to the existence of intermediate
extension headers.  And, this does not only apply to routing headers,
but also to all other kinds of extension headers.

But I don't think this issue requires an update on the spec.  After
all, ICMPv6 error messages basically only work in a best-effort
manner.

The only problematic case, as far as I can see, would be ICMPv6 too
big messages for path MTU discovery.  In this case, however, we can
still update the MTU information gradually; we first update the MTU
information to the intermediate destination stored in the destination
address field of the inner IPv6 packet.  Then succeeding packets will
go farther.  And, eventually, we can at least reach at the
intermediate destination without seeing an ICMPv6 too big error.  Then
the IPv6 destination address will be updated to the next intermediate
destination (which might be the final one), and we can still reach
there by the similar steps.

> It seems inconsistent to me to allow such a large non-fragmentable header. 
 
This is also true, but this is not specific to routing headers
either.  And, again, I don't see this is a bug of protocol
specification to be fixed.  First, this would still work for links
with a larger link MTU.  Secondly, at least IMO, it is not unfair to
say it's the sender's responsibility to keep the unfragmentable part
not exceeding the path MTU (if not, the sender can detect the error,
at least theoretically).

					JINMEI, Tatuya