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
On 3 aug 2009, at 17:46, Rémi Després wrote:
if in charge of of an SIIT (which I am not either), I would ensure
that rather than discarding IPv4 zero-checksum datagrams it forwards
them with its zero checksum.
That's pointless, because the IPv6 spec, against which implementations
have
Le 4 août 09 à 13:35, Iljitsch van Beijnum a écrit :
On 3 aug 2009, at 17:46, Rémi Després wrote:
if in charge of of an SIIT (which I am not either), I would ensure
that rather than discarding IPv4 zero-checksum datagrams it
forwards them with its zero checksum.
That's pointless,
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
Hi,
On 2009-8-4, at 16:27, Rémi Després wrote:
You seem to have missed that the proposal includes a relaxation of
the constraint that zero-checksum UDP datagrams MAY be accepted by
hosts ion the future, just to avoid unnecessary black holes in case
of v4 to v6 translations.
isn't it a
Le 4 août 09 à 16:30, Lars Eggert a écrit :
Hi,
On 2009-8-4, at 16:27, Rémi Després wrote:
You seem to have missed that the proposal includes a relaxation of
the constraint that zero-checksum UDP datagrams MAY be accepted by
hosts ion the future, just to avoid unnecessary black holes in case
On Tue, 4 Aug 2009, Rémi Després wrote:
Le 4 ao?t 09 ? 13:35, Iljitsch van Beijnum a écrit :
On 3 aug 2009, at 17:46, Rémi Després wrote:
if in charge of of an SIIT (which I am not either), I would ensure that
rather than discarding IPv4 zero-checksum datagrams it forwards them with
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).
On Tue, 4 Aug 2009, Rémi Després wrote:
Le 4 ao?t 09 ? 16:30, Lars Eggert a écrit :
Hi,
On 2009-8-4, at 16:27, Rémi Després wrote:
You seem to have missed that the proposal includes a relaxation of
the constraint that zero-checksum UDP datagrams MAY be accepted by
hosts ion the future,
Le 4 août 09 à 16:55, Mohacsi Janos a écrit :
On Tue, 4 Aug 2009, Rémi Després wrote:
Le 4 ao?t 09 ? 13:35, Iljitsch van Beijnum a écrit :
On 3 aug 2009, at 17:46, Rémi Després wrote:
if in charge of of an SIIT (which I am not either), I would
ensure that rather than discarding IPv4
On Tuesday 04 August 2009 17:49:25 ext Rémi Després wrote:
Le 4 août 09 à 16:30, Lars Eggert a écrit :
Hi,
On 2009-8-4, at 16:27, Rémi Després wrote:
You seem to have missed that the proposal includes a relaxation of
the constraint that zero-checksum UDP datagrams MAY be accepted by
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
Le 4 août 09 à 16:59, Mohacsi Janos a écrit :
On Tue, 4 Aug 2009, Rémi Després wrote:
Le 4 ao?t 09 ? 16:30, Lars Eggert a écrit :
Hi,
On 2009-8-4, at 16:27, Rémi Després wrote:
You seem to have missed that the proposal includes a relaxation of
the constraint that zero-checksum UDP
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
Le 4 août 09 à 17:00, Rémi Denis-Courmont a écrit :
On Tuesday 04 August 2009 17:49:25 ext Rémi Després wrote:
Le 4 août 09 à 16:30, Lars Eggert a écrit :
Hi,
On 2009-8-4, at 16:27, Rémi Després wrote:
You seem to have missed that the proposal includes a relaxation of
the constraint that
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
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
32 matches
Mail list logo
