UDP is assumed in the latest -05 version. The general text on encapsulation (at
the start of section 5.3) clarifies that this is not semantically significant
for the rest of the protocol design except in very specific cases (to do with
NAT traversal).

I agree to use UDP with RAO for query messages, which seems more extensible
(note protocol number field as 8 bits length is quite limited - I guess IANA may
more favor defining new RAO values) and allows more flexibility (for both IP
versions and convenience of encapsulation).

I would propose to close this issue by saying that UDP is used.

There may be a case for using raw-IP for IPv4, if this is simpler for
interception purposes (RAO not supported in some places). However, it seems very
hard to justify using raw-IP without RAO for IPv6 (since this would require a
router to parse past all extension headers to find the protocol number). Having
defined the encapsulation as not meaningful for the rest of the specification
(see Issue 30), this would be easy to change in the future without impacting the
rest of the protocol.

Some NSIS messages have to be addressed end-to-end but
intercepted at intermediate routers, and this imposes some
special constraints on how they can be encapsulated.  RSVPv1
[9] primarily uses raw IP with a specific protocol number
(46); a UDP encapsulation is also possible for hosts unable
to perform raw network i/o.  RSVP aggregation [15] uses an
additional protocol number (134) to bypass certain interior
   nodes.  

The critical requirements for the encapsulation at this
level are that routers should be able to identify signaling
packets for processing, and that they should not
mis-identify packets for 'normal' end-to-end user data flows
as signaling packets.  The current assumption is that UDP
encapsulation can be used for such messages, by allocating
appropriate (new) value codes for the router alert option
(RAO) [1][4] to identify NSIS messages.  Specific open
issues about how to allocate such values are discussed in
Section 9.4.

An alternative approach would be to use raw IP with the RSVP
protocol numbers and a new RSVP version number.  Although
this would provide some more commonality with existing RSVP
implementations, the NAT traversal problems for such an
encapsulation seem much harder to solve.  Specifically, any
unmodified NAT (which performed address sharing) would be
unable to process any such traffic since they need to
understand a higher-layer field (such as TCP or UDP port) to
use as a demultiplexer.