Subject: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204

From: Rémi Després <[email-masked]>
Date: Mon, 26 Mar 2012 20:57:41 +0200

Hi, all,

With some co-authors of the 4rd-U proposal, we will hold an informal meeting about it.
- subject: Clarification on what 4rd-U is designed to do, and how it does it.
- Participants: whoever is interested in a good understanding of the 4rd-U proposal. 
- place:  room 204
- time :  Tuesday 15:15 (duration depending on questions, maximum till 16:30).

The meeting can be seen as a bar BOF... without drinks in the room.

See you there if interested,
RD"

---

From: Maoke <[email-masked]>
Date: Tue, 27 Mar 2012 01:39:44 +0000

i wonder if remote participation (skype, jabber room, etc.) is available or
not. - maoke

2012/3/26 Rémi Després <[email-masked]>

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 27 Mar 2012 22:42:55 +0000

Hi Remi,

Thank you for having the informational meeting of 4rd-u. I can understand 4rd-u very much. 

As you mentioned during the informational meeting, 4rd-u defines the new type of the translation between IPv4 and IPv6 instead of MAP-E/MAP-T. Also, this new type of the translation has no relationship with the mapping rule. Hence, I think 4rd-u draft can be changed only to define the new type of the translation similar to MAP-E/MAP-T by removing any text related to mapping rule and refer to MAP for the mapping rule. In this case, it depends on deployment scenario to choose MAP-E, MAP-T or 4rd-u.

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 implementation of IPv6 stack, IPv6 stack totally removes IPv6 fragment header when IPv6 stack finds IPv6 fragment header and processes it. 

Since 4rd-u module gets the packet after IPv6 stack processes the packet, IPv6 fragment header is not present when 4rd-u module gets the packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4 information. But all information embedded in IPv6 fragment header is disappeared in IPv6 stack before 4rd-u module gets the packet. Hence, in order to keep/pass the information embedded in IPv6 fragment header to 4rd-u module, I think the existing IPv6 stack needs to be changed. 

In terms of MAP-T, IPv6 fragment header is also required but no information is embedded in IPv6 fragment header. Also, the current IPv6 implementation can give only information if there is a fragment header or not. So, MAP-T can know if there is a fragment header or not after IPv6 stack processes the packet without any change of the existing IPv6 stack.

I think MAP/4rd-u are transition technology and so it is good to eliminate any impact on the existing implementation of IPv6 stack as much as possible.

Thanks,
Tetsuya Murakami

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 28 Mar 2012 04:31:37 +0200

I do agree with Tetsuya-san's comments. 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. So then I suggest that remove checksum neutrality function from the document.

cheers,
--satoru

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 28 Mar 2012 07:22:36 +0000

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 Murakami

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 10:42:02 +0200

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 implementation of IPv6 stack, IPv6
> stack totally removes IPv6 fragment header when IPv6 stack finds IPv6
> fragment header and processes it.
>
> Since 4rd-u module gets the packet after IPv6 stack processes the
> packet, IPv6 fragment header is not present when 4rd-u module gets
> the packet. 4rd-u utilizes IPv6 fragment header to carry some of IPv4
> information. But all information embedded in IPv6 fragment header is
> disappeared in IPv6 stack before 4rd-u module gets the packet. Hence,
> in order to keep/pass the information embedded in IPv6 fragment
> header to 4rd-u module, I think the existing IPv6 stack needs to be
> changed.

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)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 10:44:34 +0200

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 implementation point of
> view.

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 
develop.

Checksum neutrality is a *big* advantage.

Simon

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 10:45:59 +0200

Hi, Tetsuya-san,

Thanks for your comments.

Le 2012-03-28 à 00:42, Tetsuya Murakami a écrit :

> As you mentioned during the informational meeting, 4rd-u defines the new type of the translation between IPv4 and IPv6 instead of MAP-E/MAP-T.

Reversible header translation, yes, thus achieving transparent tunneling of IPv4 packets.

> Also, this new type of the translation has no relationship with the mapping rule. Hence, I think 4rd-u draft can be changed only to define the new type of the translation similar to MAP-E/MAP-T by removing any text related to mapping rule and refer to MAP for the mapping rule. In this case, it depends on deployment scenario to choose MAP-E, MAP-T or 4rd-u.

The purpose of U is to remove the need for ISPs to make a deployment choice.
If U is standardized, ISPs can safely deploy THE standard, without having to make a choice.

> 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 pr…

Thanks for this confirmation.

> In terms of MAP-T, IPv6 fragment header is also required but no information is embedded in IPv6 fragment header. Also, the current IPv6 implementation can give only information if there is a fragme…

Yes, support of 4rd-U in Linux/BSD as you describe it implies an upgrade of the IPv6 module so that it conveys to higher layers not only the fact that there was an extension header, but also its contained packet ID.

However, in order to be capable to forward IPv6 fragments without packet reassembly (important for performance), BRs will have to do some processing below the API you are referring to. Different implementations are possible.

> I think MAP/4rd-u are transition technology and so it is good to eliminate any impact on the existing implementation of IPv6 stack as much as possible.

As much as possible, I agree, but if some adaptation is needed to avoid two incompatible variants, the new code is worth having.

Regards,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 28 Mar 2012 10:48:04 +0200

On 2012/03/28, at 10:44, Simon Perreault 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 existing transport protocols, and you still can't handle future protocols that people might develop.
> 

Cool. How many protocols we should support for just a *transition* mechanism?
--satoru

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 10:59:17 +0200

Le 2012-03-28 à 04:31, Satoru Matsushima a écrit :

> I do agree with Tetsuya-san's comments.

Answered separately.

> 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, the IPv4 payload has to be modified for the tunnel packet to be a valid IPv6 packet. This modification has to be made protocol per protocol. 
- RFC6145 says that CNP field wasn't needed because other address fields can be chosen to ensure checksum neutrality. the problem is that with stateless mapping rules, they cannot be chosen to ensure this. 
- CNP computation is really simple. 

Regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 11:02:19 +0200

> Cool. How many protocols we should support for just a *transition* mechanism?

The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for 
a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to 
keep providing clients with residual IPv4 for a potentially 
loooooooooooong time. So we need to be really careful to get this right, 
because we'll be stuck with what we design for a long time.

So you have two options:

a) checksum neutrality
    - no code specific to each transport prototol
    - supports all current and future transport protocols
b) checksum non-neutrality
    - additional code necessary for each transport protocol
    - limited set of supported transport protocols

Less code, more transport protocols. I think the choice is easy.

There's a reason NPTv6 and NAT64 chose checksum neutrality...

Simon

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 28 Mar 2012 11:06:27 +0200

> - Without checksum neutrality, the IPv4 payload has to be modified for the tunnel packet to be a valid IPv6 packet. This modification has to be made protocol per protocol. 

My understanding is that 4rd-u focus only on between v4 hosts, a packet looks like invalid IPv6 packet doesn't matter.

> - RFC6145 says that CNP field wasn't needed because other address fields can be chosen to ensure checksum neutrality. the problem is that with stateless mapping rules, they cannot be chosen to ensu…

Above my understanding, 4rd-u doesn't need to follow rfc6145 spec, because during the meeting, you said that 4rd-u is a brand new transport protocol.

> - CNP computation is really simple. 

Without CNP is much more simple.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 28 Mar 2012 11:17:56 +0200

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 transparency of original packet so not only the CNP, but also checksum recalculation are not required.

cheers,
--satoru

On 2012/03/28, at 11:02, Simon Perreault wrote:

> The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep providing clients with residual IPv4 for a potentially loooooooooooong time. So we need to be really careful to get this right, because we'll be stuck with what we design for a long time.
> 
> So you have two options:
> 
> a) checksum neutrality

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 11:20:35 +0200

> My understanding is that 4rd-u focus only on between v4 hosts, a packet looks like invalid IPv6 packet doesn't matter.

It does matter where some IPv6-only middle boxes do DPI (a point that justifies to standardize also T if E is standardized instead of U)

> Above my understanding, 4rd-u doesn't need to follow rfc6145 spec, because during the meeting, you said that 4rd-u is a brand new transport protocol.

Right. 4rd-U doesn't follow RFC6145. 
This point is just to emphasize that reasons that led to no CNP in RFC6145 don't apply to 4rd-U (no contradiction).

> Without CNP is much more simple.

Of course, not supporting a feature is simpler than supporting it, even if it is simple, but the benefit of this feature is then lost (in this instance, benefit is one standard behavior instead of two).

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 09:37:08 +0000

2012/3/28 Simon Perreault <[email-masked]>

> 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

misunderstanding on ICMP.
1. ICMP is not transport protocol.
2. ICMP cannot benefit from CNP at all because ICMPv4 checksum doesn't
cover the pseudo-header while ICMPv6 does.

just FYI.

- maoke

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 09:47:12 +0000

> protocols, and you still can't handle future protocols that people might

another FYI. RDP (RFC908, RFC1151) has different layout other than TCP/UDP.
anyway a special process is needed for it. "you are only concerned with L3"
is a mystery.

thanks,
maoke

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 10:20:23 +0000

>>> are only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc,
> The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a
> longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep
> providing clients with residual IPv4 for a potentially loooooooooooong
> time. So we need to be really careful to get this right, because we'll be
> stuck with what we design for a long time.
>
> So you have two options:
>
> a) checksum neutrality

FYI. Remi has clarified: no code specific to transport protocol having
destination port position and pseudo-header as same as TCP has. but other
protocols are exceptions, needing specific codes. exceptions include at
least: 1. ICMP; 2. RDP.

>   - supports all current and future transport protocols

again, supports current and future transport protocols, which follows TCP
layout and TCP checksum's pseudo-header definition.

>   - limited set of supported transport protocols

see above, CNP is also a limited improvement.

> There's a reason NPTv6 and NAT64 chose checksum neutrality...

to me, we'd better never forget Jon Postel's law for the Internet
robustness, which is written in RFC793: "be conservative in what you do, be
liberal in what you accept from others." a better world could be achieved
by having the L4-checksum adjustment as mandatory while, when possible,
having the CNP as an operational complement. as implementor, we are
conservative to consider some operation circumstances may not have CNP
instead of requiring all operators MUST doing so; as operator, we are also
conservative to consider some protocols may not have been fully supported
by the translators, and we attach the CNP in our address formation in order
to survive those protocol as better as we can.

requiring others offering anything into our standard is really an easy
life. but it is, a sort of, selfish.

thanks,
maoke

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 10:25:36 +0000

2012/3/28 Maoke <[email-masked]>

>> a longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep

grammatical erratus: ... current and future transport protocol that follows
...

---

From: Ole Trøan <[email-masked]>
Date: Wed, 28 Mar 2012 12:28:34 +0200

>   - supports all current and future transport protocols

this comes with a number of caveats.
and given that you need to look at the L4 to get the ports anyway...

>   - additional code necessary for each transport protocol

existing code. existing standard.

>   - limited set of supported transport protocols

the same issue applies above.

> There's a reason NPTv6 and NAT64 chose checksum neutrality...

NAT64??

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 12:34:34 +0200

>> There's a reason NPTv6 and NAT64 chose checksum neutrality...

Yup. RFC 6052 section 4.

Simon

---

From: Ole Trøan <[email-masked]>
Date: Wed, 28 Mar 2012 12:43:38 +0200

>>> There's a reason NPTv6 and NAT64 chose checksum neutrality...

as in "We considered reserving 16
   bits in the suffix to guarantee checksum neutrality, but declined"
??

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 12:48:29 +0200

>     bits in the suffix to guarantee checksum neutrality, but declined"

No, as in:

- The well-known prefix is intentionally checksum-neutral.

- Network-specific prefixes can be chosen so that translation is 
checksum-neutral.
(thus no need to do it in the suffix, as you quoted above)

Simon

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 10:50:08 +0000

dear Simon,

>> There's a reason NPTv6 and NAT64 chose checksum neutrality...

do you mean the following paragraph:

"In the case of stateful translation, checksum neutrality does not
eliminate checksum computation during translation, as only one of the
two addresses would be checksum neutral. We considered reserving 16
bits in the suffix to guarantee checksum neutrality, but declined

because it would not help with stateful translation and because
checksum neutrality can also be achieved by an appropriate choice of
the Network-Specific Prefix, i.e., selecting a prefix whose one's
  complement checksum equals either 0 or 0xffff."

good citation! and i would like to point out:
1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use checksum-neutral address -- liberal to others
2. as a operational option, RFC6052 considers having checksum-neutrality
through, e.g., choosing proper prefix if possible -- conservative to itself
3. comparing with RFC6145, the latter doesn't assume there MUST be a
checksum-neutral address but keep adjusting L4 checksum -- conservative to
itself

just my 2 cents. hope it helps.

- maoke

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 12:54:44 +0200

> do you mean the following paragraph:

No. See my response to Ole.

> NAT64 is also required to use checksum-neutral address -- liberal to others

Not sure what you mean. Agree that checksum neutrality does not help 
stateful NAT64. I'm talking about stateless NAT64.

> through, e.g., choosing proper prefix if possible -- conservative to itself

Yes.

> checksum-neutral address but keep adjusting L4 checksum -- conservative
> to itself

Yes.

Checksum neutrality still rocks. ;)

Simon

---

From: Maoke <[email-masked]>
Date: Wed, 28 Mar 2012 11:04:24 +0000

> Checksum neutrality still rocks. ;)

i am not against that checksum neutrality is useful but i don't think it it
wise to write it into a standard, forcing others doing. on the other hand,
even we write it in, we'd better not to have it as a reason for disabling
the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is
a wrong direction.

it is good to have a checksum-neutral address format, if situation allows,
as a deployment option, rather than a mandatory element in standard.
because it can only play the role of a complement in some cases. that's my
point.

hope it clarifies. ;-)

- maoke

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 28 Mar 2012 11:21:21 +0000

On 2012/03/28, at 1:42, Simon Perreault 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 stack similar to a tunnel/pseudo device is reasonable from the implementation point of view.

Thanks,
Tetsuya Murakami

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Mar 2012 13:49:56 +0200

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 stack similar
> to a tunnel/pseudo device is reasonable from the implementation point
> of view.

Yes of course.

IPv6 to IPv4:
- NF hook to receive IPv6 packets.
- Translate IPv6 into IPv4.
- Inject into v4 stack.

IPv4 to IPv6:
- Route(s) pointing to 4rd device.
- Translate IPv4 into IPv6.
- Inject into v6 stack.

We did something very similar in our Linux NAT64 implementation, as part 
of the Ecdysis project. See URL in my signature for source code.

That's just one possible way to implement 4rd-U on Linux. I'm sure there 
are others. And the vast majority of the code would be identical with a 
MAP or 4rd implementation since they all are so similar.

Simon

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 14:19:54 +0200

Le 2012-03-28 à 12:20, Maoke a écrit :

> FYI. Remi has clarified: no code specific to transport protocol having destination port position and pseudo-header as same as TCP has. but other protocols are exceptions, needing specific codes. exceptions include at least: 1. ICMP; 2. RDP. 

The problem with RDP exists only for shared-address CEs.
For this, the specification doesn't propose to do anything (RDP isn't more supported for shared-address CEs in U than in T or E).

> again, supports current and future transport protocols, which follows TCP layout and TCP checksum's pseudo-header definition. 
>  
> to me, we'd better never forget Jon Postel's law for the Internet robustness, which is written in RFC793: "be conservative in what you do, be liberal in what you accept from others."

Never forgotten.
Actually already applied well before stated by Jon (that was in the seventies... the old X.25 times !)

> a better world could be achieved by having the L4-checksum adjustment as mandatory while, when possible, having the CNP as an operational complement. as implementor, we are conservative to consider some operation circumstances may not have CNP instead of requiring all operators MUST doing so; as operator, we are also conservative to consider some protocols may not have been fully supported by the translators, and we attach the CNP in our address formation in order to survive those protocol as better as we can. 
> 
> requiring others offering anything into our standard is really an easy life. but it is, a sort of, selfish. 

The proposal is not to add CNP in E, only to have U instead of E+T (or just T or just E).

RD

---

From: Huangjing <[email-masked]>
Date: Wed, 28 Mar 2012 12:26:59 +0000

"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: [email-masked] [[email-masked]] on behalf of Maoke [[email-masked]]
Sent: Wednesday, March 28, 2012 19:04
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204

2012/3/28 Simon Perreault <[email-masked]<mailto:[email-masked]>>
On 03/28/12 12:50, Maoke wrote:
   Yup. RFC 6052 section 4.

Not sure what you mean. Agree that checksum neutrality does not help stateful NAT64. I'm talking about stateless NAT64.

Yes.

Yes.

i am not against that checksum neutrality is useful but i don't think it it wise to write it into a standard, forcing others doing. on the other hand, even we write it in, we'd better not to have it as a reason for disabling the L4-checksum adjustment. using CNP to REPLACE L4-checksum adjustment is a wrong direction.

it is good to have a checksum-neutral address format, if situation allows, as a deployment option, rather than a mandatory element in standard. because it can only play the role of a complement in some cases. that's my point.

hope it clarifies. ;-)

- maoke

Simon

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 19:56:44 +0200

Le 2012-03-28 à 11:17, Satoru Matsushima a écrit :

> I remember that what Remi said during the meeting, is that 4rd-u is a brand-new transport protocol

I doubt I said "brand new transport protocol":
- 4rd-U builds on a lot of previous work
- it isn't a transport-layer protocol. 
However, I did say and now confirm that, unlike -T, it doesn't use RFC6145. 
Consequently, RFC6145 doesn't need to be modified for U to be deployed.

RD

> 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.

---

From: Rémi Després <[email-masked]>
Date: Wed, 28 Mar 2012 19:56:44 +0200

RD

---

From: Huangjing <[email-masked]>
Date: Thu, 29 Mar 2012 11:19:45 +0000

just to clarify, maybe my point is not clear in the previous reply.

you said " i don't think it it wise to write it into a standard", but as i know, checksum neutral is also recommended in  http://tools.ietf.org/html/rfc6296#page-10,
it is a useful technology which can be put into a standard

Yes.

Yes.

hope it clarifies. ;-)

- maoke

Simon

---

From: Maoke <[email-masked]>
Date: Thu, 29 Mar 2012 12:38:49 +0000

在 2012年3月29日星期四，Huangjing 写道：

>  you said " i don't think it it wise to write it into a standard", but as
> i know, checksum neutral is also recommended in
> http://tools.ietf.org/html/rfc6296#page-10,

well, i should clarify i meant "...into a standard of the MAP scope." NAPT
is fine to use whatever address without need to consider much about
operation nor other devices, but MAP involves device interoperation and
operation. it'd better the standard is made conservative. - M

>
>
>   ------------------------------
> *From:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> on behalf of Maoke [[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>]
> *Sent:* Wednesday, March 28, 2012 19:04
> *To:* Simon Perreault
> *Cc:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> *Subject:* Re: [Softwires] 4rd-U informal meeting - Tuesday 15:15 Room 204
>
>
>
> 2012/3/28 Simon Perreault <[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>>
>
>  i am not against that checksum neutrality is useful but i don't think it
> it wise to write it into a standard, forcing others doing. on the other
> hand, even we write it in, we'd better not to have it as a reason for
> disabling the L4-checksum adjustment. using CNP to REPLACE L4-checksum
> adjustment is a wrong direction.
>
>  it is good to have a checksum-neutral address format, if situation
> allows, as a deployment option, rather than a mandatory element in
> standard. because it can only play the role of a complement in some cases.
> that's my point.
>
>  hope it clarifies. ;-)
>
>  - maoke
>
>
>>
>>
>> Simon
>> --