On Aug 6, 2009, at 16:11 , Margaret Wasserman wrote:
Hi Joel,
I think I understand both sides of the UDP checksum issue now...
We (or at least some of us) believe that it is a hard requirement to
support ECMP through legacy routing equipment. This equipment will
only identify flows using the 5-tuple described in the draft. These
devices do not know about UDP-Lite, and they couldn't usefully load
balance LISP traffic that was tunneled IP-in-IP, because there would
be no source port to use as a hash value for identification of the
original flow.
We (or at least some of us) are concerned about using UDP zero
checksums in IPv6, because of possible problems caused by corruption
of the source/destination IP addresses or the next header field.
These fields are protected in IPv4, even when UDP checksums are
disabled.
I have an idea that might work to satisfy both sets of concerns...
What about putting a checksum field in the LISP header? We could
checksum across the IP pseudo-header (at least for IPv6), and the
LISP header. LISP nodes that receive these packets could check the
checksum and discard packets that have been corrupted. In addition
to resolving the concerns about corruption in the IPv6 header
fields, this checksum would protect the LISP header, which contains
some one-bit fields and a nonce that would be sensitive to
corruption. We could also specify that LISP nodes that receive an
ICMP error should check this checksum in the returned packet before
acting on the error.
We would still have to make sure that we understand the impacts of
non-LISP nodes receiving corrupted LISP packets (which will probably
be that the packet is dropped, which is fine), but we wouldn't have
to worry about what happens when a LISP packet arrives at the wrong
LISP node and/or when a response is sent back to the wrong LISP node.
Thoughts?
Adding a checksum in the LISP header would mean either to shrink some
other fields or to enlarge the existing LISP header. I am not sure
that these are good ideas.
Another approach is to use the UDP source port number. So far in LISP
the source port number is selected using an hash function and ignored
on reception. This can be changed in a checksum to be checked on the
ETR.
Not sure if such an approach breaks something or goes against any RFC.
just my random thoughts....
Luigi
Margaret
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
would look when doing ECMP calculations.
And the router to date do not use the flow label.
Preliminary indications are that routers also won't use UDP-lite,
because it is a different protocol, and they don't know it has port
numbers.
The simple path forward is to allow UDP with 0 checksum.
If that is incorrect, then finding the correct path forward is
going to be hard.
Joel
Brian E Carpenter wrote:
Hi Joel,
On 2009-08-05 03:08, Joel M. Halpern wrote:
It has become clear with the passage of time that the description
of the
flow label in the original IPv6 specs served only to convince
everyone
not to use that field for anything. Even now, no one is sure
what to do
with it.
If you're referring to the lame appendix to RFC2460, that's exactly
why we wrote RFC3697. My understanding is that some stacks do set
the
flow label according to the SHOULD in RFC3697, but I'm not aware
of any deployed use cases (such as load balancing routers). The gap
is not in the basic specs but in exploitation. It's very similar to
what happened with the IPv4 TOS byte, and that took 20 years before
we (a) defined it properly and (b) began to see limited deployment,
as corporate VoIP took off.
My expectation has always been that exploitation of the flow label
would stay on the back burner until IPv6 deployment reached a
significant level, because there isn't much benefit in optimising
flow handling for <1% of the traffic. So I don't really see anything
odd in the current situation.
That said, I can't see any reason why ITRs and ETRs can't use
the flow label among themselves, in a way completely compatible
with RFC3697. But if their hardware engines can't include the
flow label in the n-tuple, that's a problem.
Brian
_______________________________________________
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
