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
Hi,
FYI, I remember M. Bagnulo were working on similar problems
related to source addresse selection mechanism, which is
described in the following expired document.
http://tools.ietf.org/html/draft-bagnulo-ipv6-rfc3484-update-00
further comments below.
This got me thinking, and here are
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
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
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
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
Any node (host or router) that configures a tunnel endpoint
is the source of packets that it originates from its tunnel
interface. As such, it may perform host-based fragmentation,
receive ICMP errors, etc. in a way that is typically associated
with a host.
Whether you view it as a router with an
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
17 matches
Mail list logo