Subject: RFC 2460 - Should the ultimate destination process Destination Options preceding the Routing Header, where the Routing Header is used?

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Sat, 28 Aug 2004 21:23:43 -0700

Depending on their placement in the IPv6 packet, D.O. are either intended
for the intermediate destinations when using the Routing Header, or for the
ultimate destination.  I do not see stated in the spec what the ultimate
destination should do with the D.O. preceding the Routing Header - D.O's
that are bound for intermediate nodes.

Should the ultimate destination also process the pre-RH D.O.?  There may be
no post-RH D.O., or there may be.

Should the next-to-last hop - the last intermediate node - strip (or zero)
the pre-RH D.O (I would think not - would cause problems for AH)?

Should the ultimate destination *only* act on the D.O. found *after* the RH,
where there is a pre-RH D.O. present?

If someone could point me to the definitive answer I would be grateful.
Thanks.

John Spence
-------------------------------
John Spence, CCSI, CCNA, CISSP
Native6, Inc.
IPv6 Training and Consulting
[email-masked]
www.native6.com
-------------------------------

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 29 Aug 2004 14:05:20 +0900

>>>>> On Sat, 28 Aug 2004 21:23:43 -0700, 
>>>>> "John Spence, CCSI, CCNA, CISSP" <[email-masked]> said:

> no post-RH D.O., or there may be.

Yes.  According to Section 4.1 of RFC2460, the pre-RH D.O is intended:

           note 1: for options to be processed by the first destination
                   that appears in the IPv6 Destination Address field
                   plus subsequent destinations listed in the Routing
                   header.

Note that the last destination in the Routing header is "the ultimate
destination".

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

---

From: "S. Daniel Park" <[email-masked]>
Date: Mon, 30 Aug 2004 20:03:52 +0900

Hi all

In case of absence of default router, we have simply added 
below text to clarify this case. Now I'd like to get a feedback
and comment on this proposal, and further take a consensus.
Let us know your view on this...:-)

Suggestion 1:
==================
RA Absence

We can imagine that if no RA is available.  Originally, [RFC2462]
made a rule of "invoke the stateful protocol if there is no router".
In this sense, it should be considered as a special case of RA with
the M/O flag.  In addition, in the absence of a router,
[I-D.ietf-ipv6-node-requirements], said those IPv6 nodes that use
DHCP for address assignment MUST initiate DHCP to obtain IPv6
addresses and other configuration information.  

If no RA appears, a node MUST initiate DHCPv6 service as 
[RFC3315] to get both address and configuration information 
regardless of M/O-Policy. The specific method of how a node 
recognize RA absence is out of scope of this document.
==================

OR

Suggestion 2:
==================
RA Absence

We can imagine that if no RA is available.  Originally, [RFC2462]
made a rule of "invoke the stateful protocol if there is no router".
In this sense, it should be considered as a special case of RA with
the M/O flag.  In addition, in the absence of a router,
[I-D.ietf-ipv6-node-requirements], said those IPv6 nodes that use
DHCP for address assignment MUST initiate DHCP to obtain IPv6
addresses and other configuration information.  

If no RA appears, a node MUST behave as if it receives an RA 
with the M flag is ON and the O flag is OFF according to its
policy values. The specific method of how a node recognize RA
absence is out of scope of this document.
==================

Thanks in advance.

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.