Joe, There are two separate issues here:
- creating a document for the current practise, with strong
enough disclaimers and at the same time trying to do it
as "right" as possible
- doing the right thing for IPv6
AFAIK, Ron is working on a new version of the current draft to
include comments from the discussion here, and to add a field
to the reserved field to make the extension a little bit better
in syntactical terms. I've promised to review and help him once
he gets a reasonable version.
I am not aware of anyone working on the IPv6 issues. I think
the MPLS WG should charter an item there is any real life
interest; otherwise it can wait, at least as far as I am
concerned. Before that we just must make sure that the
current IPv4 practise is NOT adopted for IPv6.
Now, taking a technical step back, the issues is pretty
complicated since there are different uses of MPLS. In some
cases MPLS is used more-or-less as a link layer protocol, and
the argumentation that appeared here and that you continue
holds pretty well. However, in other cases MPLS is used more
as a source routing mechanism for IP. That is, instead of
using the usual hop-by-hop IP routing based on routing tables
created by a routing protocol, the MPLS ingress router (Label
Edge Router) creates an MPLS "tunnel" (Label Switch Path) to
the MPLS egress router, using the information from the very
same routing tables.
Note that in the latter usage the route that the IP packets
take is exactly the same, using exactly the same routing
information. Hence, there is no difference between plain
IP routing and MPLS-based IP routing. The difference lies
in the forwarding plane, where in plain IP case each box in
the path examines the IP header and makes the forwarding
decision based on it while in the MPLS case the forwarding
decision is based on the MPLS label prepended to the IP
packet. In other words, in the plain IP case the forwarding
decision is done individually at each router (hop-by-hop
forwarding decision) while in the MPLS case the forwarding
decision is effectively done at the ingress router, in a
sort-of source-routing fashion.
So, while in some cases the approach where MPLS is seen as
a link layer and we define new layer 2 specific ICMP messages
(or even a different protocol) seems to be right, in the other
cases it indeed appears to be the right thing to send an
ICMP time exceeded, for example. The case really is that
there is a routing loop.
Unfortunately my current understanding stops here. I still
don't know how to tell the difference between these two uses
of MPLS in practise, i.e., in the boxes in the running network.
And I still can't make my mind of what would really be the
right thing (for IPv6).
Now, some more detailed comments:
I'm concerned about the issue of backward compatibility, notably the ways in which the use of the extensions proposed will cause existing ICMP processing to break, notably binding the length of the final field to 128 bytes, esp. considering RFC1812 recommends:
IIRC, Ron provided us with some data indicating that in *practise* not much is likely to fail. Hence, while I fully agree with you that from the specs point of view, the current MPLS practise a dubious one, it hasn't broken that much in real life. What Ron and I are currently planning to do is to use the reserved field (in those ICMP packets that have it) to indicate the new syntax. The new syntax is not pretty (and therefore should not be used for IPv6), but it is compatible with the current usage.
Given that, it seems that this new variant of ICMP message (which includes headers before IP, rather than IP and thereafter - which is curious enough in itself) ought to demand a new message type, which necessitates use of the "Parameter Problem" code, or the definition of other new codes. Inside those, the new format that uses a list of pointers to include MPLS information might be appropriate.
Yes, something like that should be done for IPv6. It would not be that good to specify it for IPv4, as people are not likely to do that large changes to their existing code.
Use of the "unused" area, as Ron suggested, seems inappropriate because those fields are not known to be 'cleared' by existing ICMP sources, so their value cannot be reliably used for flags IMO.
I'll let someone with more information on this to answer that. I have no real life data here.
Individual informational drafts describing existing practice seem OK, but to do so within an IETF WG seems in appropriate when the practice is in violation of existing specs, as this is.
If violating the existing specs has proven not to cause any real life problems (which I believe is the case here), it may be better to change the specs than to expect the real life to change.
At the least, there needs to be much more strong and clear wording that this technique is in violation of those specs and will thus cause problems with compliant applications.
Yes, we fully agree with that and AFAIK Ron is working to address that.
That said, I'm still very unclear on why ICMP is the right protocol to usurp for this purpose
I think I addressed this already above. What comes to your next message, I think they are good starting points were we to start making a spec for ICMPv6. --Pekka
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
