On 11 aug 2009, at 16:09, Sam Hartman wrote:
We have not reached a consensus that LISP needs to work through NATs.
I'll take your message as a statement in favor of that and a personal
opinion that they need to.
Please put me down in the that's insane column.
In your previous mail you wrote:
This is an interesting idea, and I think it is worth exploring.
= this is a typical IPv6 idea (:-)...
However, there are a couple of issues to overcome...
Would you perform DAD on these addresses before you use them? Or
would you somehow
In your previous mail you wrote:
If you want LISP on a desktop OS you need to update that OS, hence at
the same time you can patch it to handle the 0 UDP checksum
consequently.
= I disagree, it is easy to implement LISP in user mode (using
the tun/tap interface/device driver for
On Aug 13, 2009, at 16:56 , Francis Dupont wrote:
In your previous mail you wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at
the same time you can patch it to handle the 0 UDP checksum
consequently.
= I disagree, it is easy to implement LISP in user mode
On Aug 11, 2009, at 4:41 , Margaret Wasserman wrote:
On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote:
= in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
- if we need to vary things
On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at the same time you can patch it to handle the 0 UDP checksum
consequently. I do not see any real issue here.
So, if I want LISP on a non-open-source desktop, you think
On Aug 11, 2009, at 14:23 , Margaret Wasserman wrote:
On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at the same time you can patch it to handle the 0 UDP checksum
consequently. I do not see any real issue here.
Noel == Noel Chiappa j...@mercury.lcs.mit.edu writes:
From: Francis Dupont francis.dup...@fdupont.fr the O UDP
checksum proposal obsoletes all the today deployed nodes which
check them (so all hosts I know and perhaps a lot of routers
too)
Noel OK, so what are the other
In your previous mail you wrote:
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of
routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
=
On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote:
= in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
- if we need to vary things between a pair of IPv6 xTRs it should
be enough (and
Hi Noel,
On Aug 7, 2009, at 3:31 PM, Noel Chiappa wrote:
From: Francis Dupont francis.dup...@fdupont.fr
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set of
data I have access to (servers serving web content to the internet
users):
32,945,810,591 packets received, 0 dropped due to bad checksum (ip
header checksum)
Does UDP-Lite work through NAT
boxes? (LISP has a mobile-node mode, which we would like to see
work through
NAT boxes, so any proposed alternative solution has to work through
NAT boxes
too.)
For IPv6?
Sorry I didn't reply to this in the earlier message...
(1) There isn't enough NAT
On Fri, Aug 07, 2009 at 04:06:16PM -0400, Christopher Morrow wrote:
4,166,900,871 packets 0 dropped due to bad checksum
neat! (I'm also going to see if I can get some stats from a wider set
of hosts, but)
If routers check the IPv4 header checksum (which I think they are
supposed to for
In your previous mail you wrote:
- if we need to vary things between a pair of IPv6 xTRs it should
be enough (and simple/easy) to vary the addresses
The above was considered at the initial design stages of LISP, (I
think Dino may have considered this approach?); however, it
On Sun, Aug 9, 2009 at 6:14 PM, Francis Dupontfrancis.dup...@fdupont.fr wrote:
In your previous mail you wrote:
PS: IMHO this is an example of IPv6 misunderstanding: the solution
was developed for IPv4 and as it doesn't fit exactly into IPv6
in place of adjusting the solution you propose to
Noel Chiappa wrote:
From: Francis Dupont francis.dup...@fdupont.fr
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
On 6 aug 2009, at 19:00, Noel Chiappa wrote:
I see no particular issue with a network where some LAG-aware routers
do include the flow label in the hash and others don't.
Any time you have a network which is using hop-by-hop path selection
(i.e.
each node makes an independent decision on
On 5 aug 2009, at 16:16, Margaret Wasserman wrote:
What I am asking is whether IPv6 routers containing that silicon
exist in real-world deployments in large enough numbers that they
should be considered in our design choices.
The real question is how many of these routers use parallel
On 5 aug 2009, at 19:34, Christopher Morrow wrote:
You may see 2-3 year cycle on new asics for this feature to appear...
given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before
hardware is on the shelf to purchase.
You assume this requires new hardware. Although that's not
On Fri, Aug 7, 2009 at 5:52 AM, Iljitsch van Beijnumiljit...@muada.com wrote:
On 5 aug 2009, at 19:34, Christopher Morrow wrote:
You may see 2-3 year cycle on new asics for this feature to appear...
given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before
hardware is on the
In your previous mail you wrote:
And I understand that current load balancers can only do this based
on a few fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest UDP ports ( and LISP=4341).
I just don't see how
Francis,
On Aug 7, 2009, at 09:24 MDT, Francis Dupont wrote:
In your previous mail you wrote:
And I understand that current load balancers can only do this based
on a few fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest
Hi Margaret,
Apologies for the delay, but it took some time to follow-up with some
vendors. See below.
On Aug 5, 2009, at 12:33 MDT, Margaret Wasserman wrote:
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
Shane, thanks for infusing this discussion with some data.
On 7 aug 2009, at 20:05, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums as the
preferred short-term solution when IPv6 is being used
On Aug 7, 2009, at 12:21 MDT, Iljitsch van Beijnum wrote:
Shane, thanks for infusing this discussion with some data.
On 7 aug 2009, at 20:05, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums as
On Wed, Aug 5, 2009 at 5:07 PM, Margaret Wassermanm...@sandstorm.net wrote:
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we (as a
group) are assuming that the reasons for requiring ipv6 udp checksums
as stated +10 years
From: Francis Dupont francis.dup...@fdupont.fr
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
I'm told by
On Aug 7, 2009, at 2:59 PM, Christopher Morrow wrote:
On Wed, Aug 5, 2009 at 5:07 PM, Margaret
Wassermanm...@sandstorm.net wrote:
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we
(as a
group) are assuming that the
On 7 aug 2009, at 21:31, Noel Chiappa wrote:
I'm told by some people that UDP-Lite isn't a standard yet? Or is
it? (It
seems to have a protocol number issued?)
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Protocol 136, RFC 3828.
Does UDP-Lite work through NAT
On Fri, Aug 7, 2009 at 3:42 PM, Marshall Eubankst...@americafree.tv wrote:
On Aug 7, 2009, at 2:59 PM, Christopher Morrow wrote:
On Wed, Aug 5, 2009 at 5:07 PM, Margaret Wassermanm...@sandstorm.net
wrote:
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all...
CCing the IAB because I think we are reaching a slippery architectural
slope. Hopefully they can help us out.
On 7 aug 2009, at 20:43, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums as
the
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
I must be slow this morning.
I am not sure which of two possible (similar) problems this checksum is
supposed to help.
1) Due to in-network corruption, the LISP packet arrives at some
non-LISP entity which has something listening at whatever UDP port the
packet now ha as a destination.
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
I told myself I would stay out of this, but I can't help
but point out that if the SEAL-FS header were used instead
of the UDP/LISP headers there would only be 4 bytes exposed
to corruption instead of 16. And, if one of the SEAL-FS
header fields is corrupted there is no danger of causing
Hi Fred,
There are three things we are trying to address here:
- We want to support load balancing through legacy systems that only
support load balancing based on the 5-tuple of IP src/dest address,
protocol/next header and UDP or TCP src/dest ports. To meet this goal,
we need a UDP (or
From: Brian E Carpenter brian.e.carpen...@gmail.com
I see no particular issue with a network where some LAG-aware routers
do include the flow label in the hash and others don't.
Any time you have a network which is using hop-by-hop path selection (i.e.
each node makes an
From: Margaret Wasserman m...@sandstorm.net
In addition ... this checksum would protect the LISP header, which
contains some one- bit fields and a nonce that would be sensitive to
corruption.
This is an issue I had identified a while back, and looked then to see if
undetected
Margaret,
-Original Message-
From: Margaret Wasserman [mailto:m...@sandstorm.net]
Sent: Thursday, August 06, 2009 9:15 AM
To: Templin, Fred L
Cc: ipv6@ietf.org; l...@ietf.org
Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]
Hi Fred,
There are three things
Hi Fred,
On Aug 6, 2009, at 1:42 PM, Templin, Fred L wrote:
How are non-TCP/UDP flows handled by these legacy systems
today? For example, 6to4 uses ip-proto-41.
My understanding is that these flows will not be handled well...
Since ECMP load balancers will have limited information
Margaret,
-Original Message-
From: Margaret Wasserman [mailto:m...@sandstorm.net]
Sent: Thursday, August 06, 2009 1:10 PM
To: Templin, Fred L
Cc: ipv6@ietf.org; l...@ietf.org
Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]
Hi Fred,
On Aug 6, 2009, at 1:42
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.
The issue isn't whether the hardware engines can't include
On 5 aug 2009, at 1:26, Vince Fuller wrote:
Specifying some alternate reality and hoping that the operational
world will
modify its behavior to match
Isn't that the business the IETF is in?
doesn't seem very practical, particularly since
one of LISP's virtues is that it requires no
Hi Joel,
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
Hi Joel,
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
On Wed, 5 Aug 2009, Margaret Wasserman wrote:
Do you really believe that enough IPv6 routers have shipped with
this sort of ECMP behavior in _hardware_ that we need to consider
that legacy deployment? I'm somewhat skeptical that this could be
the case... If we're going to make design
Margaret,
On Aug 5, 2009, at 08:12 MDT, Margaret Wasserman wrote:
Hi Joel,
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
Shane == Shane Amante sh...@castlepoint.net writes:
Shane Take a look at the following URL:
Shane http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane (Note, I can't vouch for the accuracy of the entire list,
Shane but it's about the best publicly available list I've
Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
Shane == Shane Amante sh...@castlepoint.net writes:
Shane Take a look at the following URL:
Shane http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane (Note, I can't vouch for the accuracy of the entire list,
Shane but
On Wed, Aug 5, 2009 at 12:50 PM, Shane Amantesh...@castlepoint.net wrote:
Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
Shane == Shane Amante sh...@castlepoint.net writes:
Shane Take a look at the following URL:
Shane http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane == Shane Amante sh...@castlepoint.net writes:
Shane With respect to #2, SP's have been mandating that they only
Shane buy v6- capable HW for the last /several years/ as part of
Shane the normal growth/ replacement cycle of network equipment.
Shane So, yes, this equipment
Reading this discussion, there seem to be a small number of practical
choices.
If the vendor hardware that is / will be handling IPv6 can handle the
flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to use the flow label seems sensible. (This is about what
will be
On Wed, Aug 5, 2009 at 1:43 PM, Sam Hartmanhartmans-i...@mit.edu wrote:
Shane == Shane Amante sh...@castlepoint.net writes:
Shane With respect to #2, SP's have been mandating that they only
Shane buy v6- capable HW for the last /several years/ as part of
Shane the normal growth/
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
vendors to adopt the IPv6 flow-label as input-keys to their hash-
calculations for LAG/ECMP, it takes [a lot] of time to see that
materialize in the field.
On Wed, Aug 5, 2009 at 2:33 PM, Margaret Wassermanm...@sandstorm.net wrote:
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage vendors
to adopt the IPv6 flow-label as input-keys to their hash-calculations for
Hi Joel,
On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote:
Reading this discussion, there seem to be a small number of
practical choices.
If the vendor hardware that is / will be handling IPv6 can handle
the flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to
The basic model is that ECMP works by hashing all the fields.
Therefore, you need two related properties:
1) You need those fields to be stable across all the packets in a flow
in one direction. (There is absolutely no need for the answer to be the
same in the reverse direction, as there is no
On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote:
What was the original reason for removing the ability to do zero
checksums on udp in v6? Are we sure that that decision is still
sensible/appropriate in today's internet/world?
I have not been around long enough to have been there when
On Wed, Aug 5, 2009 at 3:32 PM, Margaret Wassermanm...@sandstorm.net wrote:
On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote:
What was the original reason for removing the ability to do zero
checksums on udp in v6? Are we sure that that decision is still
sensible/appropriate in today's
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we (as a
group) are assuming that the reasons for requiring ipv6 udp checksums
as stated +10 years ago are still valid, I don't see data supporting
that fact.
There are some
On 2009-08-05 11:26, Vince Fuller wrote:
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.
The issue isn't
62 matches
Mail list logo
