In terms of CNP, CNP needs to be calculated every time if the packet is toward
to outside of domain because the embedded IPv4 address could be different. So,
I think there is no difference between CNP and recalculation of L4 checksum
from the implementation point of view.
Thanks,
Tetsuya
Hi Gang,
Thanks for your reply. Please see in lines.
Regards!
Jiang Dong
Tsinghua University
2012-03-28
From: GangChen
Date: 2012-03-28 00:30
To: jiangdong345
CC: Kevin Y; Softwires WG
Subject: Re: [Softwires]Path to move forward with 4rdŠ
2012/3/27, Jiang Dong jiangdong...@gmail.com:
Hi Gang
2012/3/28 Maoke fib...@gmail.com
*1. consider a case where 2 CEs, 1 hop apart in IPv6 domain, establish
EBGP session over IPv6 with their 4rd addresses as the loopback addresses
and ttl-security is set to, e.g., 254, in order to protect the peer from
receiving attack messages sending by a
Le 2012-03-28 à 05:21, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
Le 2012-03-27 à 13:12, Maoke a écrit :
2012/3/27 Rémi Després despres.r...@laposte.net
With TTL transparency added, I don't see what would be missing, even with
all requirements you expressed.
On 03/28/12 00:42, Tetsuya Murakami wrote:
Also, as I mentioned during the meeting, I double-checked the current
implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6
stack gives received IPv6 packet to 4rd-u module after processing it.
But, according to the current
On 03/28/12 09:22, Tetsuya Murakami wrote:
In terms of CNP, CNP needs to be calculated every time if the packet
is toward to outside of domain because the embedded IPv4 address
could be different. So, I think there is no difference between CNP
and recalculation of L4 checksum from the
On 2012/03/28, at 10:59, Rémi Després wrote:
On the other hand, I couldn't understand the reason of why the CNP is
needed. Since 4rd-u focus on support to communicate between ipv4 hosts, L4
checksum consistency could be agnostic from any kind of 4rd-u nodes.
- Without checksum neutrality,
I remember that what Remi said during the meeting, is that 4rd-u is a brand-new
transport protocol which doesn't need to follow rfc6145 translation spec. If it
is true, 4rd-u doesn't need to take care checksum consistency of any kind of L4
protocols.
On the other word, 4rd-u can support
Le 2012-03-28 à 11:06, Satoru Matsushima a écrit :
On 2012/03/28, at 10:59, Rémi Després wrote:
On the other hand, I couldn't understand the reason of why the CNP is
needed. Since 4rd-u focus on support to communicate between ipv4 hosts, L4
checksum consistency could be agnostic from any
2012/3/28 Rémi Després despres.r...@laposte.net
1. nobody can think the leftmost bit of Hop Limit in IPv6 header is marked
as unused or unspecified (actually it is often used). you'd better to
update RFC2460 first.
No need for any update AFAIK.
significant semantics change without
2012/3/28 Rémi Després despres.r...@laposte.net
Le 2012-03-28 à 06:10, Satoru Matsushima a écrit :
FYI, section 5 of RFC5082 (
http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique
that TTL is used to help tunnel packets security. Anyway,
On 2012/03/27, at 14:02, Rémi
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 09:22, Tetsuya Murakami wrote:
In terms of CNP, CNP needs to be calculated every time if the packet
is toward to outside of domain because the embedded IPv4 address
could be different. So, I think there is no difference
Le 2012-03-28 à 11:30, Maoke a écrit :
2012/3/28 Rémi Després despres.r...@laposte.net
Le 2012-03-28 à 06:10, Satoru Matsushima a écrit :
FYI, section 5 of RFC5082 (http://tools.ietf.org/html/rfc5082#section-5.2)
generalize a technique that TTL is used to help tunnel packets
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you
are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc,
etc, etc. You need a lot of code to handle all
2012/3/28 Maoke fib...@gmail.com
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you
are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc,
etc, etc.
On the contrary, there is a big difference. The difference is that you are
only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc,
etc, etc. You need a lot of code to handle all existing transport
protocols, and you still can't handle future protocols that people might
On 03/28/12 12:28, Ole Trøan wrote:
There's a reason NPTv6 and NAT64 chose checksum neutrality...
NAT64??
Yup. RFC 6052 section 4.
Simon
--
DTN made easy, lean, and smart -- http://postellation.viagenie.ca
NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca
STUN/TURN server
2012/3/28 Rémi Després despres.r...@laposte.net
Le 2012-03-28 à 11:30, Maoke a écrit :
2012/3/28 Rémi Després despres.r...@laposte.net
Le 2012-03-28 à 06:10, Satoru Matsushima a écrit :
FYI, section 5 of RFC5082 (
http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique
There's a reason NPTv6 and NAT64 chose checksum neutrality...
NAT64??
Yup. RFC 6052 section 4.
as in We considered reserving 16
bits in the suffix to guarantee checksum neutrality, but declined
??
cheers,
Ole
___
Softwires mailing list
On 03/28/12 12:43, Ole Trøan wrote:
There's a reason NPTv6 and NAT64 chose checksum neutrality...
NAT64??
Yup. RFC 6052 section 4.
as in We considered reserving 16
bits in the suffix to guarantee checksum neutrality, but declined
No, as in:
- The well-known prefix is intentionally
On 03/28/12 12:50, Maoke wrote:
Yup. RFC 6052 section 4.
do you mean the following paragraph:
No. See my response to Ole.
1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use checksum-neutral address -- liberal to others
Not sure what
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 12:50, Maoke wrote:
Yup. RFC 6052 section 4.
do you mean the following paragraph:
No. See my response to Ole.
1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use
On 03/28/12 13:21, Tetsuya Murakami wrote:
Depends how you implement it. I can think of at least one way to do
it on Linux without touching the IPv6 stack. (with NF hooks)
Yes. It could be possible. But NAT44 requires a network device. If
NAT44 is also utilized, a 4rd-u module attached to IPv6
Le 2012-03-28 à 12:20, Maoke a écrit :
2012/3/28 Simon Perreault simon.perrea...@viagenie.ca
On 03/28/12 10:48, Satoru Matsushima wrote:
On the contrary, there is a big difference. The difference is that you are
only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc,
i am not against that checksum neutrality is useful but i don't think it it
wise to write it into a standard ..
Checksum neutral is also recommended in
http://tools.ietf.org/html/rfc6296#page-10
From: softwires-boun...@ietf.org [softwires-boun...@ietf.org] on
Folks,
According to your agenda, we haven't received the followings slides.
Please send your slides to Alain and me asap.
http://www.ietf.org/proceedings/83/agenda/agenda-83-softwire.htm
3 Tetsuya Murakami / Ole Troan (Map team)
MAP Encapsulation (MAP-E) specification
26 matches
Mail list logo
