I'd be very concerned if the IETF consensus was to introduce a change to
the UDP checksum without fully evaluating the implications for the
network and before considering the procedures by which new protocols
could access a zero-checksum mode.
As I understand, the proposal to update RFC 2460
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum field to 0.
Could you tell us how to achieve this on commonly
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum
Given that LISP ITRs work by intercepting packets that are not addressed
to them, a host implementation would need to be able to intercept
packets in the stack. That is going to need some ability to modify
kernel behavior.
(Yes, I think we will see LISP enabled hosts. I don't think mobility
I believe that saying ITRs don't receiving packets. is a linguistic
step that only confuses people. ITRs receive unencapsulated packets
from the site, and encapsulate them in LISP headers (assuming mappings
are already available.) Now, one can argue that the ITR function in the
router does
Given that LISP ITRs work by intercepting packets that are not
addressed to them, a host implementation would need to be able to
intercept packets in the stack. That is going to need some
ability to modify kernel behavior.
(1) ITRs don't receive packets. They encapsulate packets.
(2)
Joel Given that LISP ITRs work by intercepting packets that are
Joel not addressed to them, a host implementation would need to
Joel be able to intercept packets in the stack. That is going
Joel to need some ability to modify kernel behavior.
I'm trying to figure out how an ITR
I believe that saying ITRs don't receiving packets. is a
linguistic step that only confuses people.
You are right, but your text wasn't clear if the packets were coming
from the site or from the core. So I assumed you were referring to the
Map-Request or Data-Probe case.
ITRs receive
Maybe I was missing a bet. You would have to direct all the packets
from the host back to user space to be processed, since it is only the
LISP logic that can decide whether the packet should be tunneled or not.
But if they support that concept, then it can be done.
And yes, that does seem to
Joel Given that LISP ITRs work by intercepting packets that are
Joel not addressed to them, a host implementation would need to
Joel be able to intercept packets in the stack. That is going
Joel to need some ability to modify kernel behavior.
I'm trying to figure out how an ITR does
On Aug 11, 2009, at 18:01 , Joel M. Halpern wrote:
Given that LISP ITRs work by intercepting packets that are not
addressed to them, a host implementation would need to be able to
intercept packets in the stack. That is going to need some
ability to modify kernel behavior.
We already
On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote:
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the packet to
userspace for processing.
We call LISP
On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote:
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the packet to
userspace for processing.
We call LISP
Dino == Dino Farinacci d...@cisco.com writes:
Dino We call LISP tunnels as dynamic encapsulating tunnels
Dino where an implementation must not implement the tunnel as a
Dino logical interface. The implementation cannot scale if it
Dino does this. You get the level of indirection
Dino == Dino Farinacci d...@cisco.com writes:
Dino We call LISP tunnels as dynamic encapsulating tunnels
Dino where an implementation must not implement the tunnel as a
Dino logical interface. The implementation cannot scale if it
Dino does this. You get the level of indirection by
Hi Dino,
On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote:
Why couldn't LISP be implemented as a logical interface that
encapsulates or not based on the contents of the LISP Mapping cache
and the results of mapping lookups?
Because you could have 100K of them. Interface data structures
On Aug 11, 2009, at 20:05 , Dino Farinacci wrote:
On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote:
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the
I think this is off topic. If you want to continue the discussion,
send me email privately.
Hi Dino,
On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote:
Why couldn't LISP be implemented as a logical interface that
encapsulates or not based on the contents of the LISP Mapping
cache and the
On Aug 11, 2009, at 2:45 PM, Dino Farinacci wrote:
I was talking about running an ITR as a logical interface on a LISP-
aware end-node or a home gateway, so I'm not talking about
something that would need to scale to handle 100K simultaneous
connections.
Doesn't matter. You can still talk
On Aug 11, 2009, at 20:28 , Margaret Wasserman wrote:
Hi Dino,
On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote:
Why couldn't LISP be implemented as a logical interface that
encapsulates or not based on the contents of the LISP Mapping
cache and the results of mapping lookups?
Because
References: f3fc18ff-e085-47e9-8376-2c4da00d9...@americafree.tv fa1a0c09-fde5-4acd-aea1-476b090c7...@cisco.com c3c481ad-5ab6-462c-a48c-f16e968de...@nokia.com
c8f93853-fb91-4abc-9cf5-e599fd274...@cisco.com 0e71fc61-5a42-4c5a-a22a-69b3213a9...@nokia.com
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum field to 0.
Could you tell us how to achieve this on commonly
I suggest that your draft
1) Indicate whether receivers should be specially configured to accept
0 checsums or whether all stacks should accept 0 checksums.
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The
Not sensible enough.
Dino
On Aug 4, 2009, at 7:58 AM, Margaret Wasserman wrote:
On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote:
What I'm saying is that *if* UDP us used, it needs to be used
according to the RFCs that capture the IETF consensus on their
use, or the IETF consensus
Hi Margaret,
On Tue 8/4/09 8:53 PM, Margaret Wasserman m...@lilacglade.org wrote:
Hi Byzek,
On Jul 30, 2009, at 8:31 PM, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can¹t do UDP checksum calculations during encapsulation
because
On 5/08/09 8:24 AM, Brian E Carpenter brian.e.carpen...@gmail.com 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
On 30 jul 2009, at 18:49, Margaret Wasserman wrote:
We need to consider what will happen if one of these packets is
received by a non-LISP node. Are you assuming that non-LISP stacks
will simply throw away these packets, because they have zero (and
therefore invalid) UDP checksums?
On 31 jul 2009, at 9:06, Rémi Denis-Courmont wrote:
Sounds like this would require a third datagram protocol number, that
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UDP-Lite really but it
seems
like there is opposition to
Iljitsch,
On Aug 4, 2009, at 05:24 MDT, Iljitsch van Beijnum wrote:
On 30 jul 2009, at 18:49, Margaret Wasserman wrote:
We need to consider what will happen if one of these packets is
received by a non-LISP node. Are you assuming that non-LISP stacks
will simply throw away these packets,
On Aug 4, 2009, at 9:08 AM, Sam Hartman wrote:
Marshall == Marshall Eubanks t...@americafree.tv writes:
Marshall Dear Brian;
Marshall On Aug 2, 2009, at 6:15 PM, Brian E Carpenter wrote:
Lars,
It seems to me that it would not violate the spirit of RFC2460
if we added a rule that
On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote:
What I'm saying is that *if* UDP us used, it needs to be used
according to the RFCs that capture the IETF consensus on their use,
or the IETF consensus must be revised.
And what we are are saying is to be practical (and sensible).
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.
To propose that encapsulators should use this field to mark the
On 4 aug 2009, at 17:08, Joel M. Halpern wrote:
And given the deployment assumptions, if we hope for LISP to be
usable over IPv6, it can not depend for correct operation ona router
feature that is not yet being delivered.
I am really starting to lose my patience here!!!
Even IF existing
Joel == Joel M Halpern j...@joelhalpern.com writes:
Joel It has become clear with the passage of time that the
Joel description of the flow label in the original IPv6 specs
Joel served only to convince everyone not to use that field for
Joel anything. Even now, no one is sure
Le 4 août 09 à 17:08, Joel M. Halpern a écrit :
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.
RFC 3697,
On 4 aug 2009, at 19:57, Rémi Després wrote:
RFC 3697, which is on standards track, specifies how to use
flowlabels.
I would personally have no objection to it's deprecation, but it's
here.
Since apparently nobody looks at it today, I'm tempted to attempt to
scavenge some header bits
On Jul 31, 2009, at 3:06 AM, Rémi Denis-Courmont wrote:
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UDP-Lite really but it
seems
like there is opposition to overloading UDP-Lite. Then the 64-
translators
would convert it
Hi Pekka,
On Jul 31, 2009, at 3:47 AM, Pekka Savola wrote:
On Thu, 30 Jul 2009, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can¹t do UDP checksum calculations during encapsulation
because it
doesn¹t have access to the entire packet. Most
Le mardi 4 août 2009 22:01:01 Margaret Wasserman, vous avez écrit :
On Jul 31, 2009, at 3:06 AM, Rémi Denis-Courmont wrote:
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UDP-Lite really but it
seems
like there is
On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
We intend to rev this shortly and comments would be appreciated.
If you do rev this document, I would like to see:
(1) An explanation of the difference in applicability between this
On Aug 4, 2009, at 7:28 AM, Iljitsch van Beijnum wrote:
On 31 jul 2009, at 9:06, Rémi Denis-Courmont wrote:
Sounds like this would require a third datagram protocol number, that
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like
Le mardi 4 août 2009 22:42:12 Margaret Wasserman, vous avez écrit :
On Aug 3, 2009, at 5:15 PM, Rémi Denis-Courmont wrote:
(1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable
choice for LISP encapsulation? When we looked into this for CAPWAP
(another IP-in-UDP/IP tunneling
Dear Margaret;
Thank you for this long list of issues/questions. They
will be addressed.
Regards
Marshall
On Aug 4, 2009, at 3:37 PM, Margaret Wasserman wrote:
On Aug 2, 2009, at 6:31 PM, Marshall Eubanks wrote:
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
We intend to rev
On 2009-08-05 06:39, Iljitsch van Beijnum wrote:
On 4 aug 2009, at 19:57, Rémi Després wrote:
RFC 3697, which is on standards track, specifies how to use flowlabels.
I would personally have no objection to it's deprecation, but it's here.
Since apparently nobody looks at it today, I'm
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
Hi Byzek,
On Jul 30, 2009, at 8:31 PM, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can’t do UDP checksum calculations during encapsulation
because it
doesn’t have access to the entire packet. Most hardware is
streamlined to
only
Hi Noel,
On Jul 30, 2009, at 7:33 PM, Noel Chiappa wrote:
Dino, why don't we just drop the 'inside IPv6' encapsulations from
the spec?
I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6
encapsulations could be
documented in a short non-IETF note that's posted on a personal web
page
Hi,
On 2009-8-3, at 1:15, Brian E Carpenter wrote:
It seems to me that it would not violate the spirit of RFC2460 if
we added a rule that stacks MUST follow the RFC2460 rule by default
but MAY deviate from it for duly configured tunnel end points
in routers (where router is strictly as defined
Hi Dino,
On Jul 30, 2009, at 4:25 PM, Dino Farinacci wrote:
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator
(ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how
Lars,
It seems to me that it would not violate the spirit of RFC2460 if
we added a rule that stacks MUST follow the RFC2460 rule by default
but MAY deviate from it for duly configured tunnel end points
in routers (where router is strictly as defined in section 2
of 2460 and the Note in that
Dear Brian;
On Aug 2, 2009, at 6:15 PM, Brian E Carpenter wrote:
Lars,
It seems to me that it would not violate the spirit of RFC2460 if
we added a rule that stacks MUST follow the RFC2460 rule by default
but MAY deviate from it for duly configured tunnel end points
in routers (where router
Since we're up-levelling the discussion, I don't understand why one
would use UDP as a router-router protocol in the first place,
especially for IPv6, where the chance that the packet will hit a NAT
are probably exactly zero.
Because when you use tunnel encapsulation, core routers attached
From: Lars Eggert lars.egg...@nokia.com
Alternatively, you could pick a different encapsulation
Dino, why don't we just drop the 'inside IPv6' encapsulations from the spec?
I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6 encapsulations could be
documented in a short non-IETF
On Thu, 30 Jul 2009 21:25:29 +0200, Lars Eggert lars.egg...@nokia.com
wrote:
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator (ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how
On Fri, Jul 31, 2009 at 3:14 AM, Dino Farinaccid...@cisco.com wrote:
Because we want to make all combinations work. Because we want IPv6 to be
real.
Why move it to another draft when the same contention will occur.
The opponents just have to face the music. And if they are going to take
On Thu, 30 Jul 2009, byzek wrote:
It's not about performance; a large percentage of the currently-deployed
hardware can¹t do UDP checksum calculations during encapsulation because it
doesn¹t have access to the entire packet. Most hardware is streamlined to
only provide the first n bytes of a
Hi,
could you share some data on how much of a performance impact we're
talking about here? I was under the (maybe naive) impression that
checksum offloading was practically ubiquitous these days.
One of the problems with IPv6 is that is so similar to IPv4 but
different enough to cause pain
Because we want to make all combinations work. Because we want IPv6 to
be real.
Why move it to another draft when the same contention will occur.
The opponents just have to face the music. And if they are going to
take issue with this, what about the bigger more critical issues? Will
From: Dino Farinacci d...@cisco.com
Because we want to make all combinations work.
I wasn't saying to drop support for 'IPvN in IPv6' encapsulations from the
protocol, or the implementations. I was just saying take it out of the _RFC_.
Why move it to another draft when the same
Now, if a transport protocol is used for tunneling IP inside its
payload, it no longer strictly needs to checksum-protect its payload
*if* you require for the inner IP packet and its payload to be
protected by some sort of checksum.
Right, agree.
My point is that allowing this for this
From: Lars Eggert lars.egg...@nokia.com
if a transport protocol is used for tunneling IP inside its payload, it
no longer strictly needs to checksum-protect its payload *if* you
require for the inner IP packet and its payload to be protected by some
sort of checksum.
RIP is a router/router protocol and uses UDP...
SNMP is used to manage routers and uses UDP...
Yes, I wish UDP had never been invented so that people would write
transports that actually did what they intended, but folks use UDP
instead and build the transport in the application.
On Jul
j...@mercury.lcs.mit.edu (Noel Chiappa) writes:
The UDP checksum in the outer header on LISP user-data does nothing, is
expensive/impossible to compute (depending on the hardware), and therefore the
correct practical engineering choice is to not compute it.
You will probably eventually see
-Original Message-
From: Fred Baker [mailto:f...@cisco.com]
RIP is a router/router protocol and uses UDP...
SNMP is used to manage routers and uses UDP...
Yes, I wish UDP had never been invented so that people would write
transports that actually did what they intended, but
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the outer
On Thu, Jul 30, 2009 at 12:49 PM, Margaret Wassermanm...@lilacglade.org wrote:
Since we have standards-track protocols that indicate that UDP checksums
must not be zero in IPv6 (for good reasons), I believe that we should use
(enumerate good reasons pls)
valid UDP checksums in IPv6 outer
Thanks,
As promised in 6man, I'll make a longer email on why I think setting the
IPv6 UDP Checksum to zero is *not* the same as for IPv4 and what the
implications are. We touched on this briefly in TSV today, but I'd like
to take a little time to check the arguments - it seems there are many
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator (ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how much of a performance impact we're
talking about here? I was under
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the outer
From: Lars Eggert lars.egg...@nokia.com
This is in direct conflict with what RFC2460 says, and I'd personally
would find it problematic to approve publication of an Experimental
protocol that did this, unless there was an IETF consensus on a
standards-track document that
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator (ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how much of a performance impact we're
talking about here? I was under
We need to consider what will happen if one of these packets is
received by a non-LISP node. Are you assuming
Non-LISP nodes cannot decapsulate LISP packets so they don't have this
problem. ;-)
Zero UDP checksums are build in an outer UDP header by an ITR, and an
ETR which decapsulates
-Original Message-
From: Dino Farinacci [mailto:d...@cisco.com]
Sent: Thursday, July 30, 2009 4:30 PM
We also need to consider the possibility that a packet will be
received by a different LISP node than the one for which it was
intended, or that it will arrive at the
Hi,
On 2009-7-30, at 22:22, Noel Chiappa wrote:
From: Lars Eggert lars.egg...@nokia.com
This is in direct conflict with what RFC2460 says, and I'd personally
would find it problematic to approve publication of an Experimental
protocol that did this, unless there was an IETF consensus on a
Hi,
could you share some data on how much of a performance impact we're
talking about here? I was under the (maybe naive) impression that
checksum offloading was practically ubiquitous these days.
One of the problems with IPv6 is that is so similar to IPv4 but
different enough to cause pain
On 29 jul 2009, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator
(ITR and PTR) not incurred additional work when encapsulating
packets. The main LISP spec indicates:
(1) The UDP checksum in the outer header MUST be set to 0 by an
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the outer packet in
IPv6 encapsulations, the other a fixed
78 matches
Mail list logo
