On 2009-8-11, at 19:55, Dino Farinacci wrote:
If we changed the text in the LISP draft from MUST to MAY, would
we still need to write the accompanying document to RFC 2460?
Maybe Lars can comment on this.
In my opinion, any change from the MUST in RFC2460 requires updating
RFC2460.
Lars
Fred,
Your proposal seems to me in the best direction.
For a full agreement, it would however be appropriate IMHO to be more
precise:
- A v4 to v6 translator MAY (for efficiency) not recalculate
checksums of UDP datagrams received with zero checksums.
- If it doesn't recalculate them, it
On 2009-8-11, at 19:55, Dino Farinacci wrote:
If we changed the text in the LISP draft from MUST to MAY, would
we still need to write the accompanying document to RFC 2460?
Maybe Lars can comment on this.
In my opinion, any change from the MUST in RFC2460 requires updating
RFC2460.
Lars
that of course begs the question of what a system that forwards
traffic from an interface to a tunnel-like encapsulation is; I tend to
think that it did something with a packet not directed to it and is
therefore a router, but your text below would suggest that it is a host.
On Aug 13,
On Aug 13, 2009, at 12:39 AM, Lars Eggert wrote:
In my opinion, any change from the MUST in RFC2460 requires updating
RFC2460.
No problem. Rip out of 2460-bis anything that is not related to IPv6,
and say that it MUST be implemented as a change to RFC 768 or whatever
else. That's what
Hi,
yes, because RFC2460 says MUST use always and the intent here is to
loosen that restriction for LISP and AMT.
(And I'm sure Noel will again call this red-tape legalese, but the
fact is that this change revises the standing IETF consensus, and
there's a process for that.)
Lars
On
Le 13 août 09 à 17:33, Fred Baker a écrit :
that of course begs the question of what a system that forwards
traffic from an interface to a tunnel-like encapsulation is; I tend
to think that it did something with a packet not directed to it and
is therefore a router,
The distinction
Lars == Lars Eggert lars.egg...@nokia.com writes:
Lars Hi, yes, because RFC2460 says MUST use always and the
Lars intent here is to loosen that restriction for LISP and AMT.
Lars (And I'm sure Noel will again call this red-tape legalese,
Lars but the fact is that this change
Cc: Margaret Wasserman; ipv6@ietf.org; l...@ietf.org; Dino Farinacci; Noel
Chiappa
Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue
Le 13 août 09 à 17:33, Fred Baker a écrit :
that of course begs the question of what a system that forwards
traffic from an interface
Ack. Thanks for the answer.
Dino
On Aug 13, 2009, at 9:21 AM, Lars Eggert wrote:
Hi,
yes, because RFC2460 says MUST use always and the intent here is
to loosen that restriction for LISP and AMT.
(And I'm sure Noel will again call this red-tape legalese, but the
fact is that this change
Sam Hartman wrote:
Lars == Lars Eggert lars.egg...@nokia.com writes:
Lars Hi, yes, because RFC2460 says MUST use always and the
Lars intent here is to loosen that restriction for LISP and AMT.
Lars (And I'm sure Noel will again call this red-tape legalese,
Lars but the fact is
On Aug 13, 2009, at 4:54 PM, Brian Haberman wrote:
Sam Hartman wrote:
Lars == Lars Eggert lars.egg...@nokia.com writes:
Lars Hi, yes, because RFC2460 says MUST use always and the
Lars intent here is to loosen that restriction for LISP and AMT.
Lars (And I'm sure Noel will again call
The chairs of 6MAN would like to here feedback on these drafts as
they apply to the problem spaces raised (AMT, v4/v6 translators, and
LISP).
From my perspective, AMT and LISP both have the same requirements in
terms of performance and having encapsulation work well over LAGs. It
turns
Copying ipv6@ietf.org for a question.
If we changed the text in the LISP draft from MUST to MAY, would
we still need to write the accompanying document to RFC 2460?
Maybe Lars can comment on this.
See below for details.
Dino
On Aug 11, 2009, at 9:47 AM, Margaret Wasserman wrote:
On Aug
UDP Checksum: this field MUST be transmitted as 0 and ignored on
receipt by the ETR. Note, even when the UDP checksum is transmitted
as 0 an intervening NAT device can recalculate the checksum and
rewrite the UDP checksum field to non-zero. For performance reasons,
the ETR MUST ignore the
UDP Checksum: this field MUST be transmitted as 0 and ignored on
receipt by the ETR. Note, even when the UDP checksum is
transmitted
as 0 an intervening NAT device can recalculate the checksum and
rewrite the UDP checksum field to non-zero. For performance
reasons,
the ETR
16 matches
Mail list logo
