Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Lars Eggert
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

Re: source address selection revisited

2009-08-13 Thread Arifumi Matsumoto
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

Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]

2009-08-13 Thread Francis Dupont
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

Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]

2009-08-13 Thread Francis Dupont
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Rémi Després
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Dino Farinacci
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Fred Baker
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,

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Fred Baker
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

Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]

2009-08-13 Thread Luigi Iannone
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Lars Eggert
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Rémi Després
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Sam Hartman
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

RE: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Templin, Fred L
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Dino Farinacci
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Brian Haberman
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Marshall Eubanks
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

Re: [lisp] Judging Consensus on the UDP Checksum Issue

2009-08-13 Thread Dino Farinacci
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