Extended the text (mainly in Section 4.3.1, also in Section 4.3.4 and Section 9)
to be explicit about how the GIST specification provides the required message
processing rules for packets carrying the RAO and how this should be called up
when RAO value assignments are requested by NSLPs.  Also, made the prohibition
on packet fragmentation in Q-mode absolute in Section 5.3.2.1.  Added an
informative Appendix C on deployment issues with the RAO in IPv4.

RAO processing rules: in 4.3.1:

   Q-mode encapsulation:  Where GIST is sending messages to be
      intercepted by the appropriate peer rather than directly addressed
      to it (in particular, Query messages), these are UDP encapsulated,
      and MAY include an IP router alert option (RAO) if required by the
      MRM.  Each signalling node can therefore see every such message,
      but unless it exactly matches the Q-mode encapsulation rules
      (Section 5.3.2) it MUST be forwarded transparently at the IP
      level.  If it does match, the GIST MUST check the NSLPID in the
      common header.  The case where the NSLPID does not match a local
      signalling application at all is considered below in
      Section 4.3.4; otherwise, the message MUST be passed up to the
      GIST layer for further processing.

   Several different RAO values may be used by the NSIS protocol suite.
   GIST itself does not allocate any RAO values (for either IPv4 or
   IPv6); assignments are made for NSLPs using MRMs that use the RAO in
   the Q-mode encapsulation.  The assignment rationale is discussed in
   [15].  Note that the RAO value for an NSLPID may be different for
   IPv4 and IPv6.  For all assignments associated with NSIS, the RAO
   specific processing is the same and is as defined by this
   specification, here and in Section 4.3.4 and Section 5.3.2.

and in section 9:

      Every other NSLPID that uses an MRM which requires RAO usage MUST
      be associated with a specific RAO value; multiple NSLPIDs MAY be
      associated with the same value.  RAO value assignments require a
      specification of the processing associated with messages that
      carry the value.  NSLP specifications MUST normatively depend on
      this document for the processing, specifically Section 4.3.1,
      Section 4.3.4 and Section 5.3.2.

Fragmentation related text: in 5.3.2.1:

   It is possible that fragmented datagrams including an RAO will not be
   correctly handled in the network; furthermore, some of the checks
   that a datagram is a Q-mode packet depend on data beyond the IP
   header.  Therefore the sender MUST set the Don't Fragment (DF) bit in
   the IPv4 header.  Note that all MRMs require S=1 for at least some
   retransmissions, so ICMP errors related to fragmentation will be seen
   at the Querying node.

New appendix C:

Appendix C.  Deployment Issues with Router Alert Options

   The GIST peer discovery handshake (Section 4.4.1) depends on the
   interception of Q-mode encapsulated IP packets (Section 4.3.1 and
   Section 5.3.2) by routers.  There are two fundamental requirements on
   the process:

   1.  Packets relevant to GIST must be intercepted.

   2.  Packets not relevant to GIST must be forwarded transparently.

   This specification defines the GIST behaviour to ensure that both
   requirements are met for a GIST-capable node.  However, GIST packets
   will also encounter non-GIST nodes, for which requirement (2) still
   applies.  If non-GIST nodes block Q-mode packets, GIST will not
   function.  It is always possible for middleboxes to block specific
   traffic types; by using a normal encapsulation for Q-mode traffic at
   the UDP level, GIST allows NATs at least to pass these messages
   (Section 7.2.1), and firewalls can be configured with standard
   policies.  However, where the Q-mode encapsulation uses a Router
   Alert Option (RAO) at the IP level this can lead to additional
   problems.  The situation is different for IPv4 and IPv6.

   The IPv4 RAO is defined by [3], which defines the RAO format with a
   2-byte value field; however, only one value (zero) is defined and
   there is no IANA registry for further allocations.  It states that
   unknown values should be ignored (i.e. the packets forwarded as
   normal IP traffic); however, it has also been reported that some
   existing implementations simply ignore the RAO value completely (i.e.
   process any packet with an RAO as though the option value was zero).
   Therefore, the use of non-zero RAO values cannot be relied on to make
   GIST traffic transparent to existing implementations.  (Note that it
   may still be valuable to be able to allocate non-zero RAO values for
   IPv4: this makes the interception process more efficient for nodes
   which do examine the value field, and makes no difference to nodes
   which - incorrectly - ignore it.  Whether or not non-zero RAO values
   are used does not change the GIST protocol operation, but needs to be
   decided when new NSLPs are registered.)

   The second stage of the analysis is therefore what happens when a
   non-GIST node which implements RAO handling sees a Q-mode packet.
   The RAO specification simply states that "Routers that recognize this
   option shall examine packets carrying it more closely (check the IP
   Protocol field, for example) to determine whether or not further
   processing is necessary."  There are two possible basic behaviours
   for GIST traffic:

   1.  The "closer examination" of the packet is sufficiently
       intelligent to realise that the node does not need to process it
       and should forward it.  This could either be by virtue of the
       fact that the node has not been configured to match IP-
       Protocol=UDP for RAO packets at all, or that even if UDP traffic
       is intercepted the port numbers do not match anything locally
       configured.

   2.  The "closer examination" of the packet identifies it as UDP, and
       delivers it to the UDP stack on the node.  In this case, it can
       no longer be guaranteed to be processed appropriately.  Most
       likely it will simply be dropped or rejected with an ICMP error
       (because there is no GIST process on the destination port to
       deliver it to).

   Analysis of open-source operating system source code shows the first
   type of behaviour, and this has also been seen in direct GIST
   experiments with commercial routers, including the case when they
   process other uses of the RAO (i.e.  RSVP).  However, it has also
   been reported that other RAO implementations will exhibit the second
   type of behaviour.  The consequence of this would be that Q-mode
   packets are blocked in the network and GIST could not be used.  Note
   that although this caused by some subtle details in the RAO
   processing rules, the end result is the same as if the packet was
   simply blocked for other reasons (for example, many IPv4 firewalls
   drop packets with options by default).

   The GIST specification allows two main options for circumventing
   nodes which block Q-mode traffic in IPv4.  Whether to use these
   options is a matter of implementation and configuration choice.

   o  A GIST node can be configured to send Q-mode packets without the
      RAO at all.  This should avoid the above problems, but should only
      be done if it is known that nodes on the path to the receiver are
      able to intercept such packets.  (See Section 5.3.2.1.)

   o  If a GIST node can identify exactly where the packets are being
      blocked (e.g. from ICMP messages), or can discover some point on
      the path beyond the blockage (e.g. by use of traceroute or by
      routing table analysis), it can send the Q-mode messages to that
      point using IP-in-IP tunelling without any RAO.  This bypasses the
      input side processing on the blocking node, but picks up normal
      GIST behaviour beyond it.

   If in the light of deployment experience the problem of blocked
   Q-mode traffic turns out to be widespread and these techniques turn
   out to be insufficient, a further possibility is to define an
   alternative Q-mode encapsulation which does not use UDP.  This would
   require a specification change.  Such an option would be restricted
   to network-internal use, since operation through NATs and firewalls
   would be much harder with it.

   The situation with IPv6 is rather different, since in that case the
   use of non-zero RAO values is well established in the specification
   ([8]) and an IANA registry exists.  The main problem is that several
   implementations are still immature: for example, some treat any RAO-
   marked packet as though it was for local processing without further
   analysis.  Since this prevents any RAO usage at all (including the
   existing standardised ones) in such a network, it seems reasonable to
   assume that such implementations will be fixed as part of the general
   deployment of IPv6.

See also the minutes of the WG session at IETF#67, at
http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt and the presentation
slides at http://www3.ietf.org/proceedings/06nov/slides/nsis-1/sld1.htm

And the full follow up email thread:

Hi,

So I am pretty sure I disagree with your interpretation of existing IPv4 router
alert implementations. I have seen plenty through RSVP and RSVP-TE and they all
seem to be pretty universal in their implementation. Viz:
- if router alert is set intercept the packet
- inspect the protocol ID
- if there is a local consumer of the protocol, deliver the packet
- else re-insert the packet into the stream

Thus a legacy node receiving a packet which is GIST in UDP in IP will deliver
the packet to UDP and UDP will drop the packet. In other words, you cannot run
GIST as spec'd in a network that contains non-GIST-capable IPv4 nodes.

Your choices:
1. Ensure all nodes are GIST capable
2. Don't use IPv4
3. Change the way GIST uses router alert

It is not an option to change the definition of router alert in IPv4, and that
includes defining new router alert values. At least, this is not an option if
you want to support legacy nodes. If you propose to change the
IPv4 behaviour *and* you can guarantee that all nodes in your network will be
upgraded IPv4 implementations, then you are done.

Adrian





----- Original Message -----
From: "Robert Hancock" <robert.hancock@roke.co.uk>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>; "Ross Callon" 
<rcallon@juniper.net>
Cc: <john.loughney@nokia.com>; "Henning Schulzrinne" <hgs@cs.columbia.edu>;
<hgs+nsis@cs.columbia.edu>; "Magnus Westerlund" 
<magnus.westerlund@ericsson.com>
Sent: Monday, November 06, 2006 5:04 PM
Subject: draft-ietf-nsis-ntlp: Router Alert Issues


Hi Adrian,

I promised you an email on the router alert option/value issues, and here it is.

I have done some more detailed investigation of operating systems and routers
(i.e. I actually spoke to the implementors in more detail), and it turns out
that some of what both of us have written below is wrong. There is an underlying
problem that the RAO specs (2113/2711) are not well written, the IANA aspects
are not well specified, and implementations - especially for v6 - are at best
hostile to sensible use of the RAO, and at worst simply broken, and broken for
existing RAO use (not just for GIST). Incidentally, this would not be the first
time that the IETF has hit this topic (see especially the threads around
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1998-08/0003.html,
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1998-10/0115.html,
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1998-10/0172.html and
http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1999-01/0015.html)

However, having said all that, I believe that the RAO can still be used
correctly as described in the GIST spec (with some fine tuning for special
cases); indeed, if it couldn't be used this way, I'm not clear how it could be
used at all. Below I've written a high-level summary of what we require/expect,
and what has to be taken care of in implementation, and I've inlined some more
details in the conversation below. This will be one of the topics of the GIST
part of the NSIS session (thursday) - if you have any time this week to talk
through this or any other issues it would be really helpful (at the moment I've
implemented most of them in a working copy of the spec). I can even provide beer
to smooth the process.

cheers,

robert h.

Router Alert usage in GIST - High Level View
============================================

The ideal situation for the RAO would be as follows:
*) The presence of an RAO in a packet flags to a router that the packet needs
further analysis
- conversely, the absence of the RAO proves that no such analysis is required
*) For added efficiency, the presence of an RAO with a specific value flags to a
router that the packet needs further analysis
- conversely, the absence of the RAO or a difference in the value proves that no
such analysis is required (in other words, the RAO value allows finer
granularity in choosing what packets to look at). Unknown RAO values must be
silently ignored, i.e. forwarded.
*) If a packet needs such further analysis, the specification that mandates the
use of the RAO must define the criteria to be used to select the packet for
local processing. Those criteria might include the IP protocol number and
possibly other fields. If a packet does not match those criteria it must be
forwarded unchanged
*) The presence of an RAO in a packet is ignored by a host: the packet should be
processed as though the RAO was not present, and normal host processing rules apply.

If this was the real situation, usage of RAO in GIST would be (nearly)
trivial:
*) GIST packets to be handled specially by routers are identified by the
criteria proto=UDP, port=GIST.
*) GIST packets could have either existing or new RAO values assigned.
*) GIST packets seen by GIST unaware nodes with new RAO values will be
transparently forwarded.
*) GIST packets seen by GIST unaware nodes with existing RAO values will be
transparently forwarded, since the criteria proto=UDP, port=GIST do not match
any existing RAO users
*) RAO values would be assigned according to the requirements of the NSLP
*) GIST packets seen by GIST aware routers would be intercepted but forwarded
unless the NLSPID matches the set of NSLPs on the node; matching packets would
be processed as defined by GIST

[Wrinkle: since the criteria include data above the IP protocol number, we
really have to demand that Q-mode packets are not fragmented, else it is nearly
impossible for an implementation to decide whether to bypass them. We need to
add this to the spec, which already warns about fragmentation issues but not so
forcefully.]

The reason the situation is not ideal is that the RAO specs are unclear, the
IANA registry situation is unclear, and several existing implementations are at
best hostile and at worse broken in RAO processing. However, experimentation and
other argument suggests that this is not a problem for legacy nodes, or at least
that legacy nodes which break GIST already break existing protocols that use
RAO. Non-legacy nodes will need to updated for GIST anyway. Taking the issues in
turn:
*) It isn't clear if RAO values can be re-used. If the semantics of the RAO
really are limited to 'look at the packet more closely', then using an existing
RAO value for a new protocol *should* mean that GIST packets get forwarded since
they don't meet the matching criteria for the existing protocol. (This is
behaviour we want, and it is what we observe for IPv4 wherever we have been able
to test it.) It is not what we expect for some v6 implementations. If the
semantics of the RAO are stronger, i.e. 'the presence of RAO XXX means that the
packet MUST be protocol YYY' then re-use is not possible. This is definitely not
the case for IPv4, but might be the case for IPv6 depending on how one
interprets 2711 (which states the first semantics explicitly but also implies
the second by demanding that specifications requiring an RAO define the
processing to be done for packets that carry it). If that situation is not
recoverable, then we just need to accept that RAO value re-use is not possible
for v6, which has some impact on efficiency in some scenarios but not correctness.
*) It isn't clear if non-zero RAO values can be assigned for IPv4. There is some
possibility that actually some values are already in use (by RSVP aggregation,
rfc3175), and a draft has been written on the topic
(http://tools.ietf.org/wg/nsis/draft-mcdonald-nsis-router-alert-iana-00.txt)
. If we can't allocate non-zero RAO values for IPv4 we just have to live with
value=0 for GIST, which again has an impact on efficiency but not correctness.
*) Implementations don't handle the host behaviour correctly, in that a node
which is a router but also the final destination for a packet with RAO will in
some cases get the packet delivered twice. This can be worked around in the
implementation, however.
*) Implementations may not forward unknown RAO values silently, especially if
they already intercept some of the known ones; this seems to be mainly a problem
for IPv6. However, this is a clear violation of the specification and would
prevent any new RAO values ever being assigned for v6 for any protocol. We have
to assume that such nodes are rare.
*) Implementations do not make it easy to filter on protocol fields other than
IP protocol number (GIST requires filtering on UDP port also). Since GIST is the
first user of the RAO with UDP this is not an immediate problem, but the
specification needs to be clear that packets not matching the protocol or port
are forwarded unchanged. (Since the packets are recieved on a raw IP socket,
this is feasible without patching the OS.)

Summary: the existing GIST usage of the RAO is reasonable. The specification
needs to be strengthened on fragmentation and bypass for unknown port numbers,
and the NSIS extensibility document needs more text on RAO value assignment,
possibly depending on what happens to the RAO IANA considerations draft.
Implementation guidance needs to be made available for people fixing broken
operating systems.

> >> ----
> >> Router Alert interception
> >> ...but the
> >> current text on this is very scattered and unclear.
> >I've had a look at this. The RAO is mentioned in example text in 3.7 
> >and C, and text on which encapsulations require it is in 5.3.2/5.8.*.
> >4.3.3 mentions it on the transmit side and 4.3.4 on the forwarding 
> >(and ignoring) side. I'm not sure it would help to gather these 
> >references
> together, since
> >the RAO issues in those cases are minor aspects of a more important 
> >topic.
>
> It is OK with me to leave it scattered.
>
> >However, the critical sections would seem to be 4.3.1 and 9, which 
> >describe how the RAO influences the packet receive processing and how 
> >RAO values are associated with NSLPIDs. I take it from the points you 
> >make below that there should be a more precise description of the 
> >receive side processing, which I would
> put in 4.3.1.
>
> This would be helpful.

OK, we will make that the focal point for any revisions. (And possibly to some
extent 4.3.4 also.)

>
> >> RFC 2711 defines the Router Alert option for IPv6.
> >> The option carries a two byte field that indicates that the 
> >> datagram includes a message of a particular protocol.

On more closer reading, I think this is actually subtly unclear for a number of
reasons. 2711 can be read two ways: the "allocation of RAO value XXX for
protocol YYY" could mean either
- packets for protocol YYY must carry RAO value XXX
- packets carrying RAO XXX must be for protocol YYY And note that 'protocol'
here can be interpreted broadly - it could be 'IP Protocol number' (which the
RFC indicates, but only as an example), or a set of higher layer identifiers also.

Personally I believe that the second interpretation is more sensible, since an
RAO value most sensibly corresponds to a class of device performing a particular
type of function in the network, and it would be quite possible for this to
correspond to more than one protocol (if alternatives are developed later).
Choosing the first interpretation prevents this type of extensibility, and is I
think unnecessary - the RAO presence is not supposed to allow the node to short
circuit the analysis of the rest of the IP and upper layer headers.

However, this doesn't affect the definition of GIST. It needs to be bottomed out
before we start allocating RAO values. If it turns out that we have to live with
the first interpretation, the current text in 4.3.4 already handles the
extensibility requirements that arise within GIST itself, namely that you have
to check the NSLPID before deciding whether to process the packet.

> >> The IANA maintains a
> >> registry of values for this field, and new NSLPs could certainly be 
> >> added to this registry. The RFC states that:
> >>   The router's interest and the actions taken by employing
> >>   Router Alert MUST be specified in the RFC of the
> >>   protocol that mandates or allows the use of Router Alert
> That means
> >> that each NSLP specification must describe the processing
> - i.e. it
> >> is out of scope for GIST unless (and this might be
> sensible) a single
> >> new value is defined to indicate that the datagram carries a GIST 
> >> message. Obviously, if you do this you will need to make a new 
> >> request in section 9.
> >
> >This is also my understanding. It is expected that NSLPs
> will make the
> >RAO value requests. It is not obvious that a single value
> for GIST is
> >the correct approach, unless you believe that nodes which
> support NSIS
> >will typically support most/all signalling applications (more 
> >discussion in section 3.4 of 
> >http://tools.ietf.org/wg/nsis/draft-loughney-nsis-ext-02.txt).
>
> Right. I'm OK with either approach (or both!).

I think we are OK on this aspect then.

>
> >See below for the question of where the behaviour must
> >(MUST) be defined.
> >
> >> However, note well that a datagram that is intercepted because of 
> >> the Router Alert option will be delivered to the component for 
> >> processing the payload protocol - in this case UDP, and UDP will 
> >> deliver the GIST message to the destination port on the local host.
> >> So you need to be really careful in
> >> IPv6: if you register with your local IPv6 stack that you want to 
> >> receive intercepted Router Alert-flagged datagrams, you need to 
> >> make sure that the GIST port is enabled or the UDP stack will 
> >> drop/reject packets.
> >Yes. The various implementations discovered this early on. However, 
> >this strikes me as an implementation issue - I don't see an
> impact on
> >the protocol specification.
>
> Yeah, this is OK as an implementation issue for IPv6, but see below 
> for IPv4.

Actually, I spoke too early here. The behaviour depends strongly on the
implementation.

FreeBSD marks *all* v6 packets with *any* RAO value as being for local
processing, which is totally broken behaviour: for example, if you send an
IPv6 RSVP packet through a BSD router (which is not running RSVP), it will be
dropped with an ICMP protocol unreachable message.

Linux again treats all v6 packets with *any* RAO value the same, and does not
filter them on IP Protocol field, but sends them to a raw IP socket (not the
socket for the payload protocol) if such a raw socket for RAO-flagged datagrams
exists - otherwise the packets are forwarded correctly. In addition, if the
Linux node is actually the IP destination, *another* copy of the datagram *will*
be delivered to the local payload protocol as well as the copy on the raw socket
(which is a violation of the RFC, which says that hosts should ignore the RAO in
which case nothing should arrive on the raw socket).

(In both cases the RFC requirement to ignore unknown values silently is not
being respected.)

We haven't investigated other OSs in detail (OpenSolaris seems the least broken
so far). However, what I think it means in practice is that GIST implementors
will need to be careful, especially if RAO values are re-used.

>
> >> IPv4 is slightly less friendly than IPv6. Although the
> Router Alert
> >> option defined in RFC 2113 also has a two byte field, only
> one value
> >> (zero) is defined and there is no IANA registry of other
> values. In
> >> IPv4, an IP stack decides to intercept a Router Alert-flagged 
> >> datagram "shall examine packets carrying it more closely
> (check the
> >> IP Protocol field, for example) to determine whether or not further 
> >> processing is necessary." I think that you would be well- advised 
> >> to define the precise examination that you are requiring in the 
> >> case of GIST. Are you asking that all flagged packets are delivered 
> >> to UDP (as marked by their IP Protocol field) even though it may be 
> >> that many cannot be delivered - perhaps they are not even GIST 
> >> messages. Or are you asking that the IP stack checks such flagged 
> >> datagrams for:
> >> - IP protocol = UDP
> >> - destination port = GIST default port
> >
> >The ideal state of affairs is that there would be a registry of IPv4 
> >RAO values (like with v6), and then
> >- if the RAO values matches one used by NSIS
> >- and if IP proto = UDP
> >- and if dport = GIST
> >- then deliver to GIST
> >(If we cannot exploit the RAO value as a filter, the first test will 
> >always be true. The mechanisms for exploiting the v4 RAO value field 
> >are unclear; I am not sure if an update to 2113 is required
> to make the
> >option values allocatable in the same way as for v6. There is an 
> >individual draft in preparation which looks at this
> >question.)
>
> With respect, unless you are proposing that GIST is an IPv6-only 
> protocol, you have a bigger problem here than you portray. You are 
> saying that there is working going on to see how this can be made to 
> work for IPv4, but you are also saying that GIST is ready to become an 
> RFC.

The work is to find out whether other RAO values can be allocated. If they can
be allocated, then we should be OK because 2113 says that unknown values should
be ignored (packets forwarded). If they cannot be allocated, then we just have
to live with RAO=0 for all IPv4 GIST Q-mode packets, and we have to make sure
that existing nodes can bypass those packets if they are not running GIST (see
below for investigations). But the protocol spec is the same either way.

>
> As far as I can tell, this aspect of GIST cannot be implemented in an
> IPv4 network where there are other users of Router Alert, and where 
> not every node is GIST-capable.
>
> Your problem is not how the processing will be carried out on a 
> GIST-capable node, but what will happen on some other node in the 
> network. What will the IP stack do with the flagged packet?
> - Answer: It will treat it just like any other flagged
>   packet.
> What will the UDP stack do with the GIST message?
> - Answer: It will fail to deliver it.

Again, this depends on the implementation:
- FreeBSD ignores the RAO for v4 packets altogether. Non-GIST nodes would not
see the flagged packets at all. (RSVP is handled by looking directly for the IP
protocol number)
- Linux delivers the packets to a raw IP socket if the IP protocol number
matches. If there is no such raw socket or if the IP protocol does not match
currently in use (which should be the case since GIST is the first user of RAO
for UDP) the packet is forwarded. Note again that the packet is *not* delivered
to the UDP stack except at the end node, and indeed we *do* want an ICMP
response if there is no GIST implementation there.
- We've also tried a commercial router. We don't know how it works inside, but
even when running RSVP it forwards our GIST packets quite happily.

I think if existing implementations handled IPv4 RAO the way you suggest they
might, then it would be impossible to use the RAO for any new protocol.

>
> Now, you may be able to circumvent some of this by making some 
> statements about the environment in which GIST is assumed to run.
> These statements would need to be in the Abstract and the 
> Introduction.
>
> You could look at how to change the processing in IPv4 nodes so that 
> they do support GIST (possibly by pushing the RAO values approach).
> But that will never work for legacy nodes, so you need to describe how 
> you will use GIST in an existing network.
>
> [Hint: targeted Query messages solve this problem. But you might 
> consider this to be against the spirit of GIST 'route discovery'.]
>
> >> Bottom line:
> >> - You must recall that there will be other users of Router Alert 
> >> active in the network at the same time as GIST
> >
> >Indeed. But I don't believe this is a problem for the protocol
> >specification: we don't depend on the RAO as a
> demultiplexor
> >of GIST traffic from other traffic (and don't believe that
> anyone else
> >should use it in this way either).
>
> But you *do* do exactly that. On a node that does not support GIST, 
> you absolutely require that the UDP-wrapped GIST message is not 
> delivered to the UDP stack. You require that it is forwarded at the IP 
> layer.

Yes, and current implementations we have investigated do this (as I believe that
the spec says they should, albeit very badly).

>
> >> - You must take care that if a datagram is intercepted and 
> >> delivered to UDP, UDP will know what to do with it. UDP is not a 
> >> forwarding protocol.
> >
> >Yep. Implementations must listen on the appropriate port.
>
> The converse, however, is that if there is no implementation present, 
> the packet must not reach UDP. This seems to be missing in IPv4.

See above.

>
> >> - You must define the correct processing for any IPv6 Router Alert 
> >> options in the "owning specification" or define a new codepoint for 
> >> GIST.
> >
> >Yes. Possibly however (depending on how we end up with the whole RAO
> >question) the baseline processing should be defined in more
> detail in
> >the GIST spec, which the other documents would then call up.
> (Since the
> >RAO-specific aspects of the processing would be common to all cases.)
>
> If (and only if?) the NSLP can only exist in the presence of GIST then 
> this is a very fine approach.
>
> Consider that RSVP might be used as an NSLP. RSVP already has a router 
> alert option value defined, and processing rules already exist.
>

RSVP cannot be used directly as an NSLP; you could emulate the functionality of
RSVP in an NSLP (indeed, the QoS-NSLP does just that). There is an open issue
about whether the RAO values assigned for RSVP should/could be re-used for the
QoS-NSLP, but again this is a question for the RAO allocation stage.

Further inputs from Adrian Farrel:

Router Alert interception 
I am concerned about this process as specified. 
Perhaps my memory of IP is a little rusty? 
And perhaps I am telling you how to suck eggs, but the 
current text on this is very scattered and unclear. 


RFC 2711 defines the Router Alert option for IPv6. 
The option carries a two byte field that indicates that the 
datagram includes a message of a particular protocol. The 
IANA maintains a registry of values for this field, and new 
NSLPs could certainly be added to this registry. The RFC states that: 
  The router's interest and the actions taken by employing 
  Router Alert MUST be specified in the RFC of the 
  protocol that mandates or allows the use of Router Alert 
That means that each NSLP specification must describe the 
processing - i.e. it is out of scope for GIST unless (and 
this might be sensible) a single new value is defined to 
indicate that the datagram carries a GIST message. Obviously, 
if you do this you will need to make a new request in section 9. 


However, note well that a datagram that is intercepted 
because of the Router Alert option will be delivered to the 
component for processing the payload protocol - in this case 
UDP, and UDP will deliver the GIST message to the destination 
port on the local host. So you need to be really careful in 
IPv6: if you register with your local IPv6 stack that you 
want to receive intercepted Router Alert-flagged datagrams, 
you need to make sure that the GIST port is enabled or the 
UDP stack will drop/reject packets. 


IPv4 is slightly less friendly than IPv6. Although the 
Router Alert option defined in RFC 2113 also has a two byte 
field, only one value (zero) is defined and there is no IANA 
registry of other values. In IPv4, an IP stack decides to 
intercept a Router Alert-flagged datagram "shall examine 
packets carrying it more closely (check the IP Protocol 
field, for example) to determine whether or not further 
processing is necessary." I think that you would be well- 
advised to define the precise examination that you are 
requiring in the case of GIST. Are you asking that all 
flagged packets are delivered to UDP (as marked by their IP 
Protocol field) even though it may be that many cannot be 
delivered - perhaps they are not even GIST messages. Or are 
you asking that the IP stack checks such flagged datagrams for: 
- IP protocol = UDP 
- destination port = GIST default port 

Bottom line: 
- You must recall that there will be other users of 
Router Alert active in the network at the same time as 
GIST 
- You must take care that if a datagram is intercepted 
and delivered to UDP, UDP will know what to do with it. 
UDP is not a forwarding protocol. 
- You must define the correct processing for any IPv6 
Router Alert options in the "owning specification" or 
define a new codepoint for GIST.

Added text from Lars Eggert email discussion:

> >>>  Some IP options force packets onto a router's slow path,
> which may
> >>>  contribute to resource exhaustion. I assume that the authors have  
> >>> verified that Router Alert Options are safe to use in
> this regard?
> >
> > its difficult to be definitive. however, we do believe while not all 
> > routers can handle the RAO in their fast path, at least some can, 
> > and that from that point of view it is the safest way to
> mark packets
> > for interception which also allows a subset of the marked packets to 
> > be pulled out of the fast path for interception (which is basically 
> > a requirement for the multi-application support). Further discussion 
> > of the RAO is in the extensibility document. Basically, the path- 
> > coupling mandate of NSIS requires packet interception, and the RAO 
> > appears to have the optimum design for that.
> 
> We should involve the RTG/INT ADs here. We just had a discussion in
> the IESG on a similar mechanism that used IP options, where the  
> stance was basically that everything that forces stuff on the slow- 
> path is almost a DoS on the router CPU.

I think one needs to be careful here. Since we are talking about 
signalling to control the router, all the signalling that is relevant to the
router will almost certainly cause an impact on the router CPU. The best we can
do is to minimise the impact of signalling 
traffic which is not relevant to the router in question. Given that we're
mandated to use packet interception for path coupling 
following the basic RVSP model, this means that we need
- something in the packet that marks it as a potential
  signalling packet
- something in the packet that the router can check efficiently
  to see if the packet can be ignored
I believe the RAO is a fairly precise match for this requirement. There is more
discussion of this in section 3.4 of 
http://tools.ietf.org/wg/nsis/draft-loughney-nsis-ext-02.txt
(that text originally came from the GIST spec).

Side note: interception techniques have been a topic since the 
start of NSIS. It was one of the biggest discussion points 
during the NTLP early review (search for 'interception' at
http://www3.ietf.org/proceedings/04mar/235.htm; Dave and Fred are Oran and Baker
respectively). The point made there is that, if you are a bad person and want to
DoS the router, there are easier ways than RAO, if you can find out a router IP
address. If you are not a bad person, you want to make sure that the marked
packets are as small as possible percentage of the overall traffic, and C-mode
enables that (and the RAO design allows rapid filtering of whatever is marked).

I don't believe that the ecn-alternates use of options is strictly comparable.
ecn-alternates (and similar mechanisms) require a read-write operation on the
option field, rather than a filter comparison. Also, I assume it would apply to
a much larger 
proportion of the total traffic than we are expecting here.

> 
> >>>  Many middleboxes drop packets with IP options (Alberto
> Medina, Mark
> >>>  Allman, Sally Floyd. Measuring the Evolution of Transport 
> >>> Protocols in  the Internet. ACM Computer Communication Review, 
> >>> 35(2),
> >> April 2005.)
> >>>  Although I assume that this will mostly occur on the
> first or last
> >>>  couple of hops, this can still interfere with end-to-end NSIS  
> >>> operation.
> >
> > true. one approach would be to allow a Querying node to fall back to 
> > encapsulating without the RAO if the first message(s) fail. However, 
> > this would interact with other fallback processing (source address 
> > setting, relevant to the NAT discovery case) and would also make the 
> > interception more complex.
> 
> Encapsulation would also alleviate the possible concerns due to use
> of an IP option for the previous comment, so this might be something  
> that needs some investigation.

I am not clear on this. Note that encapsulation without using the 
RAO may make packets less likely to be dropped (solves one problem), 
but it makes the interception process harder because it requires 
5-tuple analysis (in fact, for v6 it would require complete header chain
analysis), so it makes the previous problem even worse). So 
there is a tradeoff to be made.

Update to refer to new version.

In any case, I think it is reasonable to modify the text to indicate that
selecting the RAO is part of the MRM definition rather than intrinsic to Q-mode
encapsulation. We can then point to the extensibility document for a more
long-term discussion. (Note that this doesn't affect the current protocol
operation "on the wire" itself, since all the current MRMs include an RAO.)

It is possible that to a large extent this flexibility can be accommodated by
saying that whether an RAO is required may depend on the MRM, but that all
current ones do require it. Then a more detailed discussion of the policies and
guidelines can go in the extensibility document. My personal preference would be
that for anything which requires a message to be picked out of the forwarding
path, the RAO is the right thing to use (at least as a default), even if
logically other types of filtering would also be possible.

Another issue that has arisen is whether it should be mandatory that the Q-mode
encapsulation always uses the RAO, or whether this is a function of the MRM
definition. The following from Christian Dickmann on the mailing list:

"Section 5.3.2 defines that a Q-mode encapsulated message has to contain a RAO.
In contrast, a lot of other encapsulation details are part of the definition of
the Message-Routing-Method, e.g. section 5.8.1.2 for downstream Q-mode
encapsulation for path-coupled MRM. Moving the RAO decision to the MRM
definition seems reasonable to me, as that would allow a wider range of MRMs,
but not change the semantics of the current specification.

For example, one could define a MRM which build the interception of messages on
  a specific port number. Such a MRM should NOT contain a RAO. But such a MRM
would currently require changing the GIST specification instead of just defining
a MRM."

A danger of allowing this as an option is that if nodes get into the habit of
*not* including the RAO, then nodes needing to perform interception will never
be able to rely on it being present. So they will always have to perform header
analysis down to the transport layer to be on the safe side.

So, another possibility is to allow nodes to fall back to excluding the RAO as
an option, but only after using the RAO as a default in initial Query messages
(rather like the S=0/1 decision).

Change to apply to new version

The RAO option, used in all Query-encapsulated packets, is filtered by some
middleboxes (in fact, in some cases, the whole packet containing the RAO is
filtered).

Query encapsulated packets can in fact be unambiguously identified  because they
are UDP encapsulated with a specific destination port. So, the use of the RAO is
purely a performance optimisation (to make it easier to detect such packets on
the fast path without doing full header analysis).

Should it be a deployment option to switch off the use of RAO if you believe that 
a) it's causing communications failure, and
b) the peer you are trying to detect is analysing transport headers to pick up GIST?