Subject: [Int-area] RAO for IPv4

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 11 Oct 2007 14:58:15 +0300 (EEST)

Dear all,

We have written the following I-D about the problem with current RAO 
allocations for IPv4 and IPv6. I would appreciate some feedback on the 
draft, and whether you feel something should be done, as we propose.
 
"IANA Considerations for the IPv4 and IPv6 Router Alert Option"
Andrew McDonald, Jukka Manner

http://www.ietf.org/internet-drafts/draft-manner-router-alert-iana-00.txt

The NSIS WG is CC:d, because the problem was identified while working on 
GIST.

Regards,
Jukka

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Thomas Narten <[email-masked]>
Date: Thu, 11 Oct 2007 08:33:43 -0400

>From the draft:

> 4.2.  IANA Considerations for IPv6 Router Alert Option Values
> 
>    The registry for IPv6 Router Alert Option Values should continue to
>    be maintained as specified in [RFC2711].  However, when a new
>    allocation is made in this registry an identical registration MUST be
>    made in the IPv4 Router Alert Option Values registry, or that value
>    MUST be reserved.  In the case that it is reserved rather than
>    allocated, the registry entry should say "Reserved (not to be
>    allocated) - Note: This value is allocated in the IPv4 Router Alert
>    Options registry".

Why exactly is it necessary to have the IPv4 and IPv6 number space be
consistent? What is the technical requirement/benefit here?

My own sense is that this would be "nice to have", but it is certainly
not required, and I don't see that having the numbering space be strictly
synchronized as providing compelling technical benefit.

What am I missing?

Thomas

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Oct 2007 14:59:04 +0200

Hi Thomas,

> synchronized as providing compelling technical benefit.

I would say:
If the numbers are aligned you don't need separate
mapping tables for IPv4 and IPv6.
The idea is that you map an NSLP ID, i.e. a an identifier
for a specific signaling application like QoS NSLP or
NAT/FW NSLP to an RAO value as demultiplexer.
In this case you would only
need one mapping table and not two different tables for
v4/v6. Technically you can have separate v4/v6 RAO tables,
but using only one would be easier to implement etc.

Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 11 Oct 2007 17:08:09 +0300 (EEST)

Exactly. There is no technical reason that forces a unified mapping, but 
it makes things simpler (which is always a good idea).

Jukka

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Oct 2007 14:59:04 +0200

Hi Thomas,

I would say:

Roland

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Thomas Narten <[email-masked]>
Date: Wed, 24 Oct 2007 10:31:52 -0400

Bob Hinden and I had some further offlist discussion about this.

My understanding is that the IPv4 RA option is very basic. It says
"look at this packet". The option itself doesn't contain any
additional information or "hint" as to what to look for or what the
packet contains.

The semantics of the IPv6 router alert option are different. The value
itself is used to convey additional "hints" about processing.

My sense is that the semantics of the IPv4 and IPv6 Router Alert
option are sufficiently different that sharing the name space just
doesn't make any sense.

That is, the  ID says:

    This document proposes the creation of a new IANA registry for
    managing IPv4 Router Alert Option Values.  In conjunction with
    this, it also proposes an update to the way in which IPv6 Router
    Alert Option Values are assigned in the existing IANA registry.

But there are no defined IPv4 Router Alert Option values (other than
zero), and it would be inappropriate to change the semantics of any
existing usages (too late for that) and it would also be inappropriate
to consider doing this in the absense of a specific new application
that would make use of a new value. This document does not propose
such a new usage.

Hence, at this point, I'm opposed to the actions called for in the
document. 

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Wed, 24 Oct 2007 09:56:24 -0700

I agree with Thomas on this document.

Bob

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 24 Oct 2007 22:56:54 +0300 (EEST)

Hi Thomas, Bob,

Thanks for the discussion.

The specific application that needs (well, to be precise, would greatly 
benefit) RAO is NSIS. That is why NSIS ML is CC:d.

Moreover, the RSVP spec talks about multiple RAO values, but lets it open 
as to whether IPv4 should also have those, not just IPv6.

RFC2113 also says that "The semantics of other values in the Value field 
are for further study."

The point is, is it time to study those "other values" further? At least 
GIST and the whole NSIS framework would greatly benefit from more values 
than just "0" for IPv4, and these values should be the same for IPv6 also, 
for simplified implementations.

There is a lot of discussions about RAO in the GIST spec, e.g., Sections 
4.3.1., 4.3.4., 5.3.2.1., 5.3.2.2., 6. IANA Considerations and Appendix C:

http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp/

Regards,
Jukka

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Oct 2007 14:11:44 -0700

I've got an architectural issue with any protocol having specific  
values in the RAO.  In general, that's
a poor approach, as it will (in the long term) lead to multiple  
protocols piggybacking on RAO.  Why not simply allocate another  
option on a per-protocol basis?

This also has the nice side effect that it ensures that things are  
backward compatible.

Tony

---

From: Roland Bless <[email-masked]>
Date: Thu, 25 Oct 2007 00:28:30 +0200

Hi Tony,

Tony Li wrote:
> I've got an architectural issue with any protocol having specific values
> in the RAO.  In general, that's
> protocols piggybacking on RAO.  Why not simply allocate another option
> on a per-protocol basis?
> 

Thanks for your comments. If you're interested in this topic
I'd like to point at Appendix C of the GIST draft that provides
more background information:
http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C

We had already some discussions about this and I'll
try to summarize why we choose to use the RAO (maybe other NSIS WG
members or Robert can jump in here) approach.
It was mainly driven by RSVP experience:
1) better chances of NAT and Firewall traversal, an own protocol
   number didn't work too well for RSVP (raw IP with protocol #46)
2) RSVP already used the RAO mechanism, thus lets re-use it.

The basic concept is: due to path-coupled signaling
we want to intercept signaling packets that are sent to
the data flow's destination.
Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP)
uses a specific RAO value, so a packet can bypass easily
if it carries the "wrong" RAO value. This assumes that
an implementation can specifically intercept packets
depending on the RAO value and let non-matching packets
bypass in the fast path.

I don't see the danger that "multiple protocols are piggybacking
on RAO", because only protocols will use this mechanism if
they need to _intercept_ packets, like GIST does for discovering
signaling nodes along a flow's path.
I don't understand what you mean by "allocate another option on a
per-protocol basis". Do you mean an own protocol number or a new IP
option or demultiplexing within the protocol itself (which we also do).
Could you explain this a little bit more?

Regards,
 Roland

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Oct 2007 16:39:28 -0700

Hi Roland,

> http://tools.ietf.org/html/draft-ietf-nsis-ntlp-14#appendix-C

Thanks for the reference.  I'm afraid that I don't agree with all of the
rationale presented there.

> 2) RSVP already used the RAO mechanism, thus lets re-use it.

I'm fine with reusing RAO.  That is in fact exactly what it's there  
for.  However,
RSVP does not attempt to piggyback any data into RAO.  That's where
you're diverging from the previous model and exactly where I have an
issue.

> depending on the RAO value and let non-matching packets

The whole point of RAO is to take the packet out of the fast path,
regardless of the value.  An NSIS implementation could, if it was
carefully and specifically constructed to do so, have a fast path
that did understand the signaling protocol and passed uninteresting
versions in the fast path.  There's no reason that this could not
be done with an option independent of RAO.

> signaling nodes along a flow's path.

This results in GIST using RAO as a transport, which is simply
a layering violation.  Again, there's no reason to not allocate a  
separate
option for carrying this value.  Please consider the case of
GISTv2.  What do you?  Allocate more RAO values?  What happens if
there's some other subsequent protocol that wants hop-by-hop
visibility.  Do you allocate bits for that protocol from RAO as well?
Suppose that it needs to co-exist with GIST.  Do you allocate code
points for the cross product of the two protocol code points?  What
happens if there's a third protocol?

> Could you explain this a little bit more?

I'm suggesting another IP option that has semantics independent
from RAO that would be wholly used for GIST.

Tony

---

From: Bob Hinden <[email-masked]>
Date: Wed, 24 Oct 2007 09:56:24 -0700

Bob

---

From: Roland Bless <[email-masked]>
Date: Thu, 25 Oct 2007 00:28:30 +0200

Hi Tony,

The basic concept is: due to path-coupled signaling
we want to intercept signaling packets that are sent to
the data flow's destination.
Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW NSLP)
uses a specific RAO value, so a packet can bypass easily
if it carries the "wrong" RAO value. T:36 +0200
Date: Thu, 25 Oct 2007 00:28:30 +0200
From: Roland Bless <[email-masked]>
Organization: Institute of Telematics, University of Karlsruhe
To: Tony Li <[email-masked]>
Subject: [NSIS] Re: [Int-area] RAO for IPv4
Cc: Jukka MJ Manner <[email-masked]>,
	NSIS Working Group <[email-masked]>, [email-masked]

Hi Tony,

Regards,
 Roland

his assumes that

Regards,
 Roland

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Oct 2007 14:11:44 -0700

Tony

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 25 Oct 2007 13:40:32 +0100

> that would make use of a new value. This document does not propose

It is not clear to me that there are "no defined IPv4 Router Alert 
Option values (other than zero)". The counter-example (as identified in 
section 3 of the draft we're discussing) is RSVP aggregation in RFC3175 
(in particular sections 1.4.9 and 6).

Andrew

---

From: Scott Brim <[email-masked]>
Date: Thu, 25 Oct 2007 09:16:45 -0400

I have not paid attention to NSIS recently but architecturally I find
Tony's arguments to be very persuasive.

swb

---

From: Roland Bless <[email-masked]>
Date: Thu, 25 Oct 2007 17:26:07 +0200

Hi Tony,

> rationale presented there.

Oops, good to hear another opinion.

> you're diverging from the previous model and exactly where I have an

Ok. You are referring to the fact that the NSLP-ID is
somehow mapped to the RAO value. Probably that's new,
because RSVP is only one signaling application whereas
GIST was designed to support different signaling applications
like QoS-NSLP and NAT/FW-NSLP.

> be done with an option independent of RAO.

There is no need that the fast path
understands the signaling protocol. It simply takes only those
packets out of the fast path that have a particular matching
set of RAO values, and ideally packets with other RAO values are
simply forwarded without leaving the fast path. This is especially
useful for  aggregation techniques (e.g., RFC 3175). However, if you
think about inter-domain aggregation RAO values do not help much and
that's where using a new option could be interesting indeed. So I guess
you are correct: conceptually the RAO values are shared between
different applications depending on such a functionality. Currently,
that would be: RSVP + RSVP Aggregation, GIST per NSLP + Aggregation for
QoS NSLP.

We discussed RAO things also last year at IETF-67:
see
http://www3.ietf.org/proceedings/06nov/slides/nsis-1/sld13.htm
and
http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt
One conclusion was that some existing implementations for RAO
are definitely broken, but should be fixed for RSVP anyway.
Problem with Firewalls are always expected, too.

> a layering violation.  Again, there's no reason to not allocate a separate

These are indeed good questions. For NSLP versions:
I vaguely remember discussing last year on the NSIS list
that different NSLP versions must be demultiplexed within the NSLP
itself and we do not consider to allocated a NSLP-ID per version.

> from RAO that would be wholly used for GIST.

Ok. This would probably make chances smaller that GIST
packets pass firewalls or NATs. However, GIST will not
work very well through NATs without special NAT support anyway,
so the new option should be implemented together with GIST support
in these boxes. But legacy middleboxes may break the connectivity
for GIST then. What do others think?

Regards,
 Roland

---

From: Tony Li <[email-masked]>
Date: Thu, 25 Oct 2007 08:45:23 -0700

On Oct 25, 2007, at 5:40 AM, Andrew McDonald wrote:

> Option values (other than zero)". The counter-example (as  
> identified in section 3 of the draft we're discussing) is RSVP  
> aggregation in RFC3175 (in particular sections 1.4.9 and 6).

Thanks for this reference.  After digging around some more, it  
appears clear to me that there's a little bit of a disconnect  
someplace.  I would have expected the code points defined for IPv6  
and IPv4 to be wholly identical, down to the point of there being a  
single IANA registry.

As it stands right now, there is no registry for IPv4, so the real  
reference is 2113, which only defines 0.  Yes, 3175 talk about  
defining other values but if you read the IANA considerations section  
it is not at all clear that they meant to extend this to IPv4, tho  
they certainly should have.

In any case, I agree that this is ample precedent for allocating code  
points for RAO, and undercuts my arguments completely.

Given that I no longer have a leg to stand on, I'll sit down and shut  
up.  ;-)

One request tho: while you're allocating a new code point, could you  
please clean up the IANA situation?  Please request that there be a  
single code point registry for both IPv6 and IPv4 RAO that includes  
all of the currently defined code points.

Thanks,
Tony

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 10:50:37 -0500

Hi Tony,

>As it stands right now, there is no registry for IPv4, so the 
>real reference is 2113, which only defines 0.  Yes, 3175 talk 
>about defining other values but if you read the IANA 
>considerations section it is not at all clear that they meant 
>to extend this to IPv4, tho they certainly should have.
>
>In any case, I agree that this is ample precedent for 
>allocating code points for RAO, and undercuts my arguments completely.
>
>Given that I no longer have a leg to stand on, I'll sit down 
>and shut up.  ;-)
>
>One request tho: while you're allocating a new code point, 
>could you please clean up the IANA situation?  Please request 
>that there be a single code point registry for both IPv6 and 
>IPv4 RAO that includes all of the currently defined code points.

Well, I think we in NSIS really want to do the 'right thing' so 
to speak, and we came to the conclusion that you have.  The authors
of the draft are seeking some consensus on how to move forward with
this, as this area is definitely murky.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 25 Oct 2007 16:34:37 +0100

ok, I'll bite: 

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]] 
> Sent: 25 October 2007 14:17
> To: Tony Li
> Cc: Roland Bless; Jukka MJ Manner; NSIS Working Group; 
> [email-masked]
> I have not paid attention to NSIS recently but 
> architecturally I find Tony's arguments to be very persuasive.
> 
> swb
> 
> > > Thanks for your comments. If you're interested in this topic I'd 
> > > like to point at Appendix C of the GIST draft that provides more 
> > > background information:
> > Thanks for the reference.  I'm afraid that I don't agree 
> with all of 
> > the rationale presented there.

That appendix was an attempt to capture quite intense discussions
between
the authors, routing area reviewer, and our chairs and ADs. Quite
possibly
there are things which are not ideal about it - if you have concerns I'd
be keen to understand them (might be easier not to influct that on the
mailing lists in the first instance, however).

> > 
> > 
> > > We had already some discussions about this and I'll try 
> to summarize 
> > > why we choose to use the RAO (maybe other NSIS WG members 
> or Robert 
> > > can jump in here) approach.
> > for.  However, RSVP does not attempt to piggyback any data 
> into RAO.  
> > That's where you're diverging from the previous model and exactly 
> > where I have an issue.

I don't believe either RSVP or NSIS or any other protocol is
piggybacking
data in the RAO, either for v4 or v6. (Except possibly in the case of
RSVP aggregation, see below.)

> > 
> > 
> > > Each NSIS signaling protocol (e.g, QoS NSLP or NAT/FW 
> NSLP) uses a 
> > > specific RAO value, so a packet can bypass easily if it 
> carries the 
> > > "wrong" RAO value. This assumes that an implementation can 
> > > specifically intercept packets depending on the RAO value and let 
> > > non-matching packets bypass in the fast path.
> > 
> > 
> > regardless of the value.  

That is currently the case for v4. That is not the case for v6, at
least, not according to my reading of paragraph 2 of section 2.2 of
rfc2711: 
"   Routers that recognize the option will examine datagrams carrying it
   more closely to determine whether or not further processing is
   necessary.  The router only needs to parse the packet in sufficient
   detail to decide whether the packet contains something of interest.
   The value field can be used by an implementation to speed processing
   of the datagram within the transit router."

So, the question on the table is whether that ability (to speed
processing
by looking at the value field) would be useful in the v4 case or whether
for some reason it could only ever be useful for the IPv6 case.

> > An NSIS implementation could, if it was 
> > carefully and specifically constructed to do so, have a 
> fast path that 
> > did understand the signaling protocol and passed uninteresting 
> > versions in the fast path.  There's no reason that this 
> could not be 
> > done with an option independent of RAO.

See below on the question of a separate option.

> > 
> > 
> > > I don't see the danger that "multiple protocols are 
> piggybacking on 
> > > RAO", because only protocols will use this mechanism if 
> they need to 
> > > _intercept_ packets, like GIST does for discovering 
> signaling nodes 
> > > along a flow's path.
> > 
> > 
> > This results in GIST using RAO as a transport, which is simply a 
> > layering violation.  

I'm afraid that when we are talking about relying on packet interception
in the forwarding layer to pass data to a signalling protocol handler,
the layering model is already being molested. But I agree that there
can be layering concerns. Let me consider the v6 case again, for
which there are (at least) two RAO values assigned, rsvp and mld. There
are two ways to interpret the usage of RAO-carrying packets:

1) The router logic is:
- if the packet carries RAO value = 0 it is an ICMPv6 message (IP proto
58)
with type field 130/131/132: therefore, pass it to the MLD process;
- if the packet carries RAO value = 1 it is an RSVP message (IP proto
46)
with RSVP Msg Type = 1
- otherwise forward the packet

2) The router logic is:
- I want to intercept RSVP path messages, so pick packets with RAO
value=1
out of the forwarding path and examine them more closely
- I want to intercept MLD messages, so pick packets with RAO value=0 out
of the forwarding path and examine them more closely

(1) certainly feels like a layering violation, and I think (2) is more
architecturally sound; however, the end result is pretty much the same:
RAO values are associated with specific protocols, or sub-protocols of
protocols. And RAO values for IPv6 can be associated with subprotocols
of NSIS in exactly the same way. If this is moral for IPv6 why can it
not
be for IPv4? (I'm well aware of the fact that RAO per se is much more 
important for v4 than v6 because of header chain processing issues;
however,
the ability to differentiate between different RAO users in the RAO
itself
would seem similar.)

As an aside, rfc3175 really would seem to involve a layering violation,
since the aggregation level, which is very semantically signficant for
the
RSVP processing, is carried *only* in the RAO value field and not the
RSVP messages itself. But it may be that I've misunderstood this aspect
of 3175.

> > Again, there's no reason to not allocate a 
> > separate option for carrying this value.  Please consider 
> the case of 

There will certainly be an art to allocating new RAO values. That
problem
already exists for IPv6, although the IANA considerations section of
2711
is (by today's standards) somewhat brief. That does not per se show that
the concept is not valid (but see further below).

> > > option or demultiplexing within the protocol itself 
> (which we also 
> > > do).
> > I'm suggesting another IP option that has semantics 
> independent from 
> > RAO that would be wholly used for GIST.

OK: I was initially very confused by this suggestion, because you would
end up with the 'do I look at this more closely?' check on the fast path
being something like

IF (rao-present OR (new-option-present AND value in
{interesting_values}))

rather than

IF (rao-present AND value in {interesting_values})

which certainly *looks* simpler. And in the first case, packets with
new-option 
would be forced onto the slow path in all existing routers, whereas in
the
second, marked packets could still be forwarded on the fast path in
routers 
not interested in the signalling. So while a new option is certainly
possible
(logically), I don't understand the backwards compatibility advantages. 

However, it may be the case that the current facts of life are that in
reality,
the presence of options in IPv4 packets will just be ignored; in that
case,
defining a new option might be a cleaner approach. It still seems weird
to me
that the approach to replicate IPv6 RAO functionality in IPv4 is not to
extend
the IPv4 RAO spec but to introduce a new option, but backwards
compatibility
does lead to this sort of oddity (and far worse, of course).

Bottom line:
- IPv6 RAO value filtering functionality appears to be useful. If
actually the
modern consensus is that it is overspecified and a simpler (possibly
less
optimised for certain scenarios) approach is architecturally and
practically
better, then that is a fair view. We can forget the question for IPv4
and
use a single value for IPv6; the consequence is that all nodes that
process
any signalling messages will have to process all signalling messages off
the
fast path.
- If it is still the view that value-based filtering is useful for IPv6,
there 
may still be a view that it is not useful for IPv4. However, I haven't
seen
that argument.
- If value-based filtering is useful for IPv4, you can either achieve it
by
extending rfc2113 or defining a new option for IPv4. And we can then
work out
the pros and cons of those approaches.

thanks for reading,

robert h.