Subject: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U

From: Alain Durand <[email-masked]>
Date: Wed, 1 Feb 2012 08:28:40 -0800

Dear wg,

We now have a number of documents and solutions on the table in the 4rd category: all the MAP effort, including 4rd-T & 4rd-E,
and, somehow separately, the 4rd-U effort. I will claim that there is a very large overlap between all those solution and somehow small differences.
For the sake of this discussion, I'll say the overlap is about 90%, the exact number is irrelevant, what matters is that this number is much more than 50%

I have expressed many times that, in my view, the main role of a standard process is to pick one solution when multiple are available. Not that
the others are bad, but that the fact of not choosing and pushing through the process a number of solutions that are 90% or more identical is not doing
the community any good.

Back at Beijin interim meeting, we agreed on 'publishing' a number of documents, but did not agree on status and/or recommendation
attached to 4rd-E and 4rd-T. later, 4rd-U came as an attempt at unifying then.

At stake here is not so much the organization of the document set, nor which document(s) are accepted as wg item(s) right now
on the basis that they are somehow technologically 'ready'.

At stake now is how many solutions that are 90% overlapping we are going to send to the IESG. In other words,
at stake is the capability of this wg to make clear recommendations  as to what to implement and what to deploy.

At this point in time, I think the wg as the choice between a number of paths forward:

1) Declare failure to reach consensus and stop working on this 4rd space.
2) Declare a Pyrrhic(*) victory, publish everything on the standard track without any recommendation as to which one to use
3) Declare partial victory, publish everything as Experimental, let the market decide and come back in two years
     to put the winner on the standard track.
4) Converge to a consensus toward one 'recommended' solution, publish that one as Standard track and publish the
     other ones as experimental/informational, THEN declare victory. Note that using standard track vs experimental is just one way
     to make recommendations on status, there are others, such as publishing a recommendation document or adding
     recommendation text in a boiler plate inside each document.

I'd think that we would all agree that 1) is the least preferred option.

2) might be appealing as a short term solution to (not solve) the recommendation problem we are faced with, but if we do that,
I would claim that the wg would have not done its job and would have simply added to the confusion around
which transition mechanism to choose. Hence my qualification of this solution as 'Pyrrhic' victory.

As wg co-chair, my perspective is that we should do either 3) or 4)

I would like to encourage the wg to start a discussion toward 4) on the mailing list so that we could have a productive conversation in Paris,
where I intend to ask for wg feedback on this question.

More over, 4rd-U claims to solves a number of issues that the MAP suite of documents does not address. It would be beneficial to have
a discussion on the mailing list  to see if a) those issues are important or not and b), if they are, are they properties of 4rd-U or could they be solved as well
in MAP, they just have not been addressed there yet.

In the mean time, I believe we should hold off accepting any document as wg item. I'd like to use the upcoming Paris meeting
next month as a forcing function to make progress and I encourage discussion on the mailing list on thee above topics until then.

     Alain, Softwire wg co-chair.

(*)See http:// en.wikipedia.org/wiki/Pyrrhic_victory

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 2 Feb 2012 01:16:07 -0600

Hello,

To evaluate the merits/demerits of these approaches, there can be also
be a benchmark of use cases (V6 transition network scenarios).
It may be useful to have prototypes implemented and results can be
published for these scenarios, which can help in converging and
narrowing down the methods. 

Thanks 
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alain Durand
Sent: Wednesday, February 01, 2012 9:59 PM
To: Softwires WG
Cc: Yong Cui; Ralph Droms (rdroms)
Subject: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U

Dear wg,

We now have a number of documents and solutions on the table in the 4rd
category: all the MAP effort, including 4rd-T & 4rd-E,
and, somehow separately, the 4rd-U effort. I will claim that there is a
very large overlap between all those solution and somehow small
differences.
For the sake of this discussion, I'll say the overlap is about 90%, the
exact number is irrelevant, what matters is that this number is much
more than 50%

I have expressed many times that, in my view, the main role of a
standard process is to pick one solution when multiple are available.
Not that
the others are bad, but that the fact of not choosing and pushing
through the process a number of solutions that are 90% or more identical
is not doing
the community any good.

Back at Beijin interim meeting, we agreed on 'publishing' a number of
documents, but did not agree on status and/or recommendation
attached to 4rd-E and 4rd-T. later, 4rd-U came as an attempt at unifying
then.

At stake here is not so much the organization of the document set, nor
which document(s) are accepted as wg item(s) right now
on the basis that they are somehow technologically 'ready'.

At stake now is how many solutions that are 90% overlapping we are going
to send to the IESG. In other words,
at stake is the capability of this wg to make clear recommendations  as
to what to implement and what to deploy.

At this point in time, I think the wg as the choice between a number of
paths forward:

1) Declare failure to reach consensus and stop working on this 4rd
space.
2) Declare a Pyrrhic(*) victory, publish everything on the standard
track without any recommendation as to which one to use
3) Declare partial victory, publish everything as Experimental, let the
market decide and come back in two years
     to put the winner on the standard track.
4) Converge to a consensus toward one 'recommended' solution, publish
that one as Standard track and publish the
     other ones as experimental/informational, THEN declare victory.
Note that using standard track vs experimental is just one way
     to make recommendations on status, there are others, such as
publishing a recommendation document or adding
     recommendation text in a boiler plate inside each document.

2) might be appealing as a short term solution to (not solve) the
recommendation problem we are faced with, but if we do that,
I would claim that the wg would have not done its job and would have
simply added to the confusion around
which transition mechanism to choose. Hence my qualification of this
solution as 'Pyrrhic' victory.

I would like to encourage the wg to start a discussion toward 4) on the
mailing list so that we could have a productive conversation in Paris,
where I intend to ask for wg feedback on this question.

More over, 4rd-U claims to solves a number of issues that the MAP suite
of documents does not address. It would be beneficial to have
a discussion on the mailing list  to see if a) those issues are
important or not and b), if they are, are they properties of 4rd-U or
could they be solved as well
in MAP, they just have not been addressed there yet.

In the mean time, I believe we should hold off accepting any document as
wg item. I'd like to use the upcoming Paris meeting
next month as a forcing function to make progress and I encourage
discussion on the mailing list on thee above topics until then.

(*)See http:// en.wikipedia.org/wiki/Pyrrhic_victory
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Trøan <[email-masked]>
Date: Thu, 2 Feb 2012 11:12:04 +0100

> in MAP, they just have not been addressed there yet.

here is a comparison table of the feature differences between MAP and 4rd-U.
(try a fixed width font if it doesn't survive your particular MUA mail mangling algorithm.)

Appendix A.  Comparions of stateless A+P solutions

   +-------------------------------+----------------+------------------+
   | Feature                       |       MAP      |       4rd-U      |
   +-------------------------------+----------------+------------------+
   | Encapsulation                 |        Y       |         Y        |
   | Translation                   |        Y       |         Y        |
   | Hub and Spoke mode            |        Y       |         Y        |
   | Nested CPE                    |        N       |         Y        |
   | End-user prefixes > 64        |        Y       |         N        |
   | E-mode: Support for IPv4      |        Y       |         N        |
   | options                       |                |                  |
   | T-mode: MF bit and TOS bits   |        N       |         Y        |
   | transparency                  |                |                  |
   | T-mode: Checksum              |   L4 rewrite   |        CNP       |
   | H & S set bit 79 needed       |        N       |         Y        |
   | Interface-id                  |     RFC6052    |      V octet     |
   | MAP traffic identified by     | Address/prefix |  Interception of |
   |                               |                |      V octet     |
   | Port mapping algorithm        |   GMA. Prog.   |    GMA. Fixed    |
   | Fragment forwarding on BR     |        N       |         Y        |
   | without reassembly            |                |                  |
   | Shared fragmentation id space |        N       |         Y        |
   | BR rewrite fragmentation      |        N       |         Y        |
   | MSS update                    |        Y       |         N        |
   | Complete IPv6 address /       |        Y       |         N        |
   | prefix                        |                |                  |
   | Provisioned with DHCP         |        Y       |         Y        |
   +-------------------------------+----------------+------------------+

                          Table 1: A+P comparison

let us make it clear that these two solutions are solving exactly the same problem, and they solve it in the same fundamental way (A+P). the differences we're talking about here are what whistles, bells (and dongs) we want to add on to the base specification. consider it a buffet, any feature from one of them can be applied to the other.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 2 Feb 2012 16:56:11 +0100

Hi Ole,

This kind of table you have below is IMHO the tool we need at this stage :-).

It has however to be more detailed: so far, it covers 4rd-H (the header-mapping variant of the last 4rd-U), but not 4rd-E (its encapsulation variant).
A 4 columns table would be ideal. Also, It could have a sign identifying points that are N in current drafts, but  could easily become Y if the final consensus is that they are worth the additional complexity.
I can work on it if you are interested.

More specific points below.
They can be discussed one by one.

> Appendix A.  Comparions of stateless A+P solutions

(1)It is AFAIK also a "Y" for 4rd.
(Not sure to understand the point.)

>  | E-mode: Support for IPv4      |        Y       |         N        |

(2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E but, for 4rd-E, they can easily be put back if found useful. (My vote is NO, but a WG consensus on YES for 4rd-E would not be a problem at all).

>  | T-mode: Checksum              |   L4 rewrite   |        CNP       |

(3) The functional point is guaranteeing IPv4-payload preservation, with compatibility with ALL protocols using TCP-like checksum, present of future, with checksums anywhere in the payload. 

>  | H & S set bit 79 needed       |        N       |         Y        |

(4) The functional point is to permit use cases like that of 5.3 of the last 4rd-U draft.
The added complexity for this is close to nil, and applies ONLY to H&S scenarios.

If abandoned (which is easy), it should be with due WG consciousness of  which use cases are thus abandoned.

>  | MAP traffic identified by     | Address/prefix |  Interception of |

(5) The main functional point of the V octet is to avoid interfering with subnet assignments in customer sites.
(6) Not sure to understand what you mean by "Interception of V octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to the 4rd function.

>  | Port mapping algorithm        |   GMA. Prog.   |    GMA. Fixed    |

(7)  Substantial complexity added for GMA isn't justified, in my understanding, by real use cases that would need it. 
This could easily be added to 4rd-U if so decides the WG (a waste IMHO).

>  | MSS update                    |        Y       |         N        |

(8) I found no reference to MSS in MAP-E, and no reference to MSS update in MAP-T.
Did I miss them?

>  | Complete IPv6 address /       |        Y       |         N        |

(9) Not sure what you mean by a complete IPv6 prefix. I see no functional limitation of 4rd-U with prefix lengths.

>  | Provisioned with DHCP         |        Y       |         Y        |

Cheers,
RD

---

From: Alain Durand <[email-masked]>
Date: Thu, 2 Feb 2012 09:35:08 -0800

Please, Remi, do build such a table! That would be very useful.

Alain.

Sent from my iPad

---

From: Ole Trøan <[email-masked]>
Date: Fri, 3 Feb 2012 13:25:45 +0100

Remi,

> (Not sure to understand the point.)

I might have misunderstood R-11 and R-24. it depends on the V octet.
but I suppose for any solution it is more of a deployment choice than a inherent limitation to the mechanism.

> (2) 4rd-U draft 03 has excluded IPv4 options for both 4rd-H and 4rd-E but, for 4rd-E, they can easily be put back if found useful. (My vote is NO, but a WG consensus on YES for 4rd-E would not be a…

indeed, part of the smorgasbord of features the working group can choose between.

> (3) The functional point is guaranteeing IPv4-payload preservation, with compatibility with ALL protocols using TCP-like checksum, present of future, with checksums anywhere in the payload. 

the MDT recommends L4 rewrite:
 - this is what existing implementations do
 - works for any L4 protocol (MAP has to be L4 aware for port anyway)

> If abandoned (which is easy), it should be with due WG consciousness of  which use cases are thus abandoned.

indeed.

> (5) The main functional point of the V octet is to avoid interfering with subnet assignments in customer sites.

the MDT recommendation is to set aside a prefix or an IPv6 address to terminate MAP traffic.

> (6) Not sure to understand what you mean by "Interception of V octet". IPv6 routing within CEs or BRs is sufficient to orient IPv6 packets to the 4rd function.

if classification of MAP packets versus native packets have to be done, not using the best matching prefix algorithm, but a non contiguous mask. e.g.:

 a match on:
2001:db8:1234:*:0V00:*

> This could easily be added to 4rd-U if so decides the WG (a waste IMHO).

GMA and the 4rd-U algorithm is the same algorithm. with the same bit representation on the wire.
the MAP text goes in more detail in explaining how to calculate the port ranges and so on.
4rd-U has fixed (a) the offset bits, while MAP has the same default, but allows it to be configured.

>>  | BR rewrite fragmentation      |        N       |         Y        |

btw, in 4rd-U did you intend for the BR to rewrite the fragmentation id on packets to the Internet from the CEs?
instead of making the CE use the fragmented fragmentation (sic!) space directly?

I think the fragmentation ideas are well worth considering btw.

> (8) I found no reference to MSS in MAP-E, and no reference to MSS update in MAP-T.

RFC6145 mentions it at least. I don't think MAP-E should do anything on MSS, in that case it would be part of the NAT function prior to encapsulation.

> (9) Not sure what you mean by a complete IPv6 prefix. I see no functional limitation of 4rd-U with prefix lengths.

ah, misspelling. MAP describes how to provision a complete IPv4 address or IPv4 prefix. (not IPv6 of course).

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 3 Feb 2012 15:32:42 +0100

> but I suppose for any solution it is more of a deployment choice than a inherent limitation to the mechanism.

Unless use cases showing a practical limitation of 4rd-U in this respect, this line can then be left out.
OK?

> indeed, part of the smorgasbord of features the working group can choose between.

The design team is mandated to assemble a particular proposal, and the WG then decides what to do with it, globally or piece by piece. 

> - works for any L4 protocol

Present or future without change?

> (MAP has to be L4 aware for port anyway)

> the MDT recommendation is to set aside a prefix or an IPv6 address to terminate MAP traffic.

Indeed, so that an IPv6 site to which MAP support is added may have to change its intra-site subnet assignments for this.
This is avoided with the V octet.

> if classification of MAP packets versus native packets have to be done, not using the best matching prefix algorithm, but a non contiguous mask. e.g.:

 (6.a) In BRs or CEs, the first * isn't needed because its value is fixed so that best matching works.
 (6.b) In middle boxes, if this is what you discuss, testing the V octet is sufficient. 
 (6.c) Note that use cases where middle boxes interpret tunnel packets is the case where MAP-T and 4rd-H have their functional advantages over MAP-E and 4rd-E. 

> GMA and the 4rd-U algorithm is the same algorithm. with the same bit representation on the wire.

- The 4rd-U algorithm is: "A port of the port set contains the PSID, starting at bit 4.

- The MAP algorithm is:
"1. The port number (P) of a given PSID (K) is composed of: P = R * M * j + M * K + i
Where:
 *  PSID: K = 0 to R - 1 
 *  Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, if the port numbers (0 - 4095) are excluded.
 *  Contiguous Port index: i = 0 to M - 1 
2.  The PSID (K) of a given port number (P) is determined by: 
   K = (floor(P/M)) % R
  Where:
 *  % is the modulus operator
 *  floor(arg) is a function that returns the largest integer not greater than arg."

- It has to be faced that this isn't the same algorithm. This difference is significant because the simpler the algorithm, the simpler is personnel training, and the simpler if network maintenance. 

> btw, in 4rd-U did you intend for the BR to rewrite the fragmentation id on packets to the Internet from the CEs?

 (6-bis) As explained in the draft, not for packets from ALL CEs.
 But the 4rd-U draft does propose ID rewrite in BRs for packets from CEs having shared addresses.
 Reason, explained in the draft, is that if original IDs are kept unchanged for shared-address CEs, reassembly may be broken in destination end points. 
 A discussion of this point, which so far had only been discussed verbally, is of course welcome.

> instead of making the CE use the fragmented fragmentation (sic!) space directly?

Not understood.

> ah, misspelling. MAP describes how to provision a complete IPv4 address or IPv4 prefix. (not IPv6 of course).

- Sec 5.1 says: 
"As far as mapping rules are concerned, the simplest deployment model is that in which the Domain has only one rule (the Default mapping rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to it comprising the BR /64 prefix, the V octet, a null octet, and the IPv4 address."
 Also, the use case of 5.3 uses full IPv4 addresses.
 I agree however that the text could make it clearer.

-  A Mapping rule that has Rule IPv4 prefix = 0 and EA-bits length < 32 assigns an IPv4 prefix.

Cheers,
RD

BTW, could you use my e-mail address that works in Softwire, otherwise my responses get lost.
Thanks.

---

From: Ole Trøan <[email-masked]>
Date: Fri, 3 Feb 2012 16:00:22 +0100

Remi, et al,

> I can work on it if you are interested.

the design team, chartered by the chairs, has delivered its work to the working group for consideration.
the MAP design team did its pick of features that it found useful and valuable from the veritable smorgasbord of features that have been suggested. those choices have to a large extent been discussed on the list.

we do not, in my view, have multiple competing solutions, we are rather discussing different "feature profiles".

the MAP design team has proposed one "feature profile" for the working group. Remi has proposed another.

since the design team has finished the work it set out to do, I'd rather see the feature selection discussion on a working group document.

idea: would it be possible to pull out the "feature sections" of 4rd-U and publish that as a new draft. then with detailed descriptions of the features, the working group can decide on what should be added or replaced in the MAP documents?

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Fri, 3 Feb 2012 18:45:10 +0100

Remi,

> Unless use cases showing a practical limitation of 4rd-U in this respect, this line can then be left out.

yes, to finish off this topic, what happens with 4rd-U if the End-user IPv6 prefix is e.g a /96?
and the V-bits are not adhered to?

[...]

> Present or future without change?

"without change and MAP", isn't that an oxymoron?
any A+P solution requires support for L4 protocols to extract ports.
L4 checksum rewrite, as well as port extraction will have to be supported for all new L4 protocols.
the L4 checksum rewrite approach can work with any checksum algorithm.
that said, do we really think NAT44s will be upgraded to support any new L4?

[...]

> This is avoided with the V octet.

in the MAP case where there is a single address as tunnel endpoint. that address can be taken out of a /64 used also by native. if that /64 exists on a link that the MAP CE router is not connected, the prefixes would have to be renumbered.

> (6.c) Note that use cases where middle boxes interpret tunnel packets is the case where MAP-T and 4rd-H have their functional advantages over MAP-E and 4rd-E. 

I know we've discussed the V octet a lot earlier. I can't remember all the nuances we discussed. could you summarize, e.g. in the feature draft I suggested earlier.

my main concern, is if this would add a new check to the IPv6 forwarding path, forever.

> - It has to be faced that this isn't the same algorithm. This difference is significant because the simpler the algorithm, the simpler is personnel training, and the simpler if network maintenance. 

if you were to give the algorithm to calculate the port ranges and how to extract the PSID from a port. I think you would see that you end up with the same as above. 4rd-U only shows the bit format on the wire, while MAP shows how the port ranges can be calculated.

> A discussion of this point, which so far had only been discussed verbally, is of course welcome.

I think this is a good idea.
but why couldn't the fragmentation rewrite be done on the CEs? e.g. by splitting fragmentation ID space, just like port space is split?

> -  A Mapping rule that has Rule IPv4 prefix = 0 and EA-bits length < 32 assigns an IPv4 prefix.

right, so the function here is just like MAP, so we don't need to discuss that further.

> BTW, could you use my e-mail address that works in Softwire, otherwise my responses get lost.

if you set the right From: or Reply-To: fields, the replies go to the address you like.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Sat, 4 Feb 2012 07:46:19 +0100

> Please, Remi, do build such a table! That would be very useful.

OK, will do it next week.
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 4 Feb 2012 08:39:42 +0100

> and the V-bits are not adhered to?

If the End-user doesn't support 4rd-U, nothing to be said. 
If 4rd-U is enabled, any prefix longer than /64 that matches a Mapping rule MUST have the V octet.

If any you have a case where this isn't sufficient, I will look at it.

> that said, do we really think NAT44s will be upgraded to support any new L4?

Imagine a variant of the SCTP of RFC4960 is introduced where the TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis (not a bad idea IMHO, but here just a hypothesis to answer your point). 
=> 4rd-H would be compatible with it without any evolution; RFC6145 would need an upgrade to support it.

Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the same place as usual can be mapped as usual.

> in the MAP case where there is a single address as tunnel endpoint. that address can be taken out of a /64 used also by native. if that /64 exists on a link that the MAP CE router is not connected,…

Right. 
Renumbering avoidance being a positive feature, the V octet is useful in this case.

In the case of prefixes shorter than /64, all addresses based on the subnet prefix that happens to be needed to introduce MAP would need to be renumbered. This is avoided with the V octet of 4rd-U.

Agreed?

> I know we've discussed the V octet a lot earlier. I can't remember all the nuances we discussed. could you summarize, e.g. in the feature draft I suggested earlier.

Please see above.
Also, the 4rd-U draft says:
"The V octet is a 4rd-specific mark. Its function is to ensure that 4rd does not interfere with the choice of subnet prefixes in CE sites.  It can also facilitate maintenance by facilitating distinction between 4rd Tunnel packets and native-IPv6 packets.  Within CEs, IPv6 packets can safely be routed to the 4rd function based on a /80 prefix because no internal route for native IPv6 can have a destination prefix that start with this one." 

Not understood.

> if you were to give the algorithm to calculate the port ranges and how to extract the PSID from a port. I think you would see that you end up with the same as above.

Are you sure you mean what you wrote? 
(I can't find how this would make sense: in 4rd-U, extracting the PSID knowing its length k is just extracting bits 4 to 3 + k).

> 4rd-U only shows the bit format on the wire, while MAP shows how the port ranges can be calculated.
> 

This is an alternative which has pros and cons.
- it statically reduces the number of ID shared-addresss CEs can use, a drawback.
- it significantly simplifies BRs

Personally, I think your proposal is overall better, at least as long as very high sharing ratios are avoided. A warning against such sharing ratios can be added.
Unless there are objections, a next edition of the unified draft will have it.

> if you set the right From: or Reply-To: fields, the replies go to the address you like.

I know, but when I fail to check that the right address was used, my answers do reach cc addresses and fail to reach the WG list. I then have to send a copy from the modified source. CCs addressees then receive the same message twice.
AFAIK, the Reply-to field is intended for cases where the provided address differs from the source address.
Anyway, thanks for having sent this e-mail to my mailing-list compatible address.

Cheers,
RD

---

From: Tina TSOU <[email-masked]>
Date: Sat, 04 Feb 2012 09:48:53 +0000

Sent from my iPad

> "The V octet is a 4rd-specific mark. Its function is to ensure that 4rd does not interfere with the choice of subnet prefixes in CE sites.  It can also facilitate maintenance by facilitating distin…
Assume there is a CE Router with /32 IPv6 addresses in an enterprise network.
"based on a /80 prefix" for what? Would u elaborate or reword the last sentence for better understanding for readers like me? Merci.

---

From: Rémi Després <[email-masked]>
Date: Sat, 4 Feb 2012 11:23:21 +0100

>> Le 2012-02-03 à 18:45, Ole Trøan a écrit :
...
>> ...

> "based on a /80 prefix" for what? Would u elaborate or reword the last sentence for better understanding for readers like me? Merci.

 If a CE has a /32 prefix, say p:p::/32, and some Mapping rule that derives an IPv4 prefix or address from it, all 4rd Tunnel packets sent to it have, according to the 4rd-U draft, an IPv6 destination starting with p:p:0:0:3000::/80.
 Within the CE, all packets whose destination start with this prefix can be routed, within the CE, to the 4rd function. 
 Native IPv6 packets are routed in the CE with prefixes that are either longer than the CE 4rd prefix and non-overlapping, or shorter. In both cases adding a route for the 4rd /80 doesn't impact how they are routed.
 Does this clarify?

Regards,
RD

---

From: Ole Trøan <[email-masked]>
Date: Sat, 4 Feb 2012 15:00:58 +0100

Remi,

> Native IPv6 packets are routed in the CE with prefixes that are either longer than the CE 4rd prefix and non-overlapping, or shorter. In both cases adding a route for the 4rd /80 doesn't impact how…

so what you are saying is that for an End-User IPv6 prefix of /56. there will be 256 /80 routes?

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Sun, 5 Feb 2012 10:05:09 +0100

Remi,

> If any you have a case where this isn't sufficient, I will look at it.

MAP is more flexible with regards to not depending on the V octet.

> Upgrading NAT44s to support this SCTP-bis would be trivial (ports as the same place as usual can be mapped as usual.

my point is that MAP is L4 aware anyway, and has to be modified to support any new transport protocol. since code modifications have to be made, then having a checksum neutral function at the network layer doesn't help much. you still need to change code. L4 rewrite is also more flexible in that it will support _any_ checksum algorithm, and most importantly is already implemented in every node.

> In the case of prefixes shorter than /64, all addresses based on the subnet prefix that happens to be needed to introduce MAP would need to be renumbered. This is avoided with the V octet of 4rd-U.

no, I don't think so, but I can't guarantee that I understand your use case.
as I said previously, I would encourage you to write a draft with the additional features including use cases you'd see made to MAP.

[...]

> (I can't find how this would make sense: in 4rd-U, extracting the PSID knowing its length k is just extracting bits 4 to 3 + k).

give me the algorithm to calculate the set of port ranges with 4rd-U.
my claim is that it is going to look like the description in MAP.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 6 Feb 2012 09:24:17 +0100

Le 2012-02-05 à 10:05, Ole Trøan a écrit :
...

>>>  what happens with 4rd-U if the End-user IPv6 prefix is e.g a /96?

(a) Which flexibility? To do what? 

(b) Do you negate that:
- with MAP as is, an IPv6 site may have to change its assignment of subnet prefixes to support MAP
- This is never needed with 4rd-U, thanks to the V octet.

RD

---

From: Ole Trøan <[email-masked]>
Date: Mon, 6 Feb 2012 09:33:11 +0100

Remi,

> (a) Which flexibility? To do what? 

supports arbitrary end-user IPv6 prefix length, without regard for 'magic bits' in the interface-id.

> - with MAP as is, an IPv6 site may have to change its assignment of subnet prefixes to support MAP

only if the first subnet in the end-user IPv6 prefix is used by another internal router, that isn't going to act as a MAP CE.

> - This is never needed with 4rd-U, thanks to the V octet.

renumbering is in any case going to happen in the home, and we have to design our protocols to deal with it.

can we just agree to disagree on the V-octet, and not spend any more working group time on it? it would be good if you wrote up a more detailed analysis in a separate draft, so the considerations are kept somewhere.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 6 Feb 2012 09:52:04 +0100

> my point is that MAP is L4 aware anyway, and has to be modified to support any new transport protocol. since code modifications have to be made, then having a checksum neutral function at the netwo…

Thus, you continue to negate that 4rd-U would support without any change a protocol such as, for example, a SCTP variant using TCP-like checksum instead of its CRC32c checksum.

This negation is AFAIK based on a lack of understanding:
- UDP, TCP, DCCP, SCTP have the same places for port their fields, but have their own places for their checksum fields. 
- A solution based on L4 checksum adjustment MUST know _for each protocol_ where checksum fields are placed.
- A solution based on checksum neutrality of IPv6 addresses doesn't need to know where checksum fields are placed. 
- For address sharing, knowing places of port fields is sufficient.

I added Dan as destination of this mail, hoping to have his comment.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 6 Feb 2012 10:18:00 +0100

Le 2012-02-06 à 09:33, Ole Trøan a écrit :
...
> supports arbitrary end-user IPv6 prefix length, without regard for 'magic bits' in the interface-id.

If you have a use case where CEs need longer that /64 prefixes for native IPv6, I will look at them and comment.
If CE IPv6 prefixes longer than /64 are only used to convey CE IPv4 addresses, I don't see the problem of having these addresses always starting at bit 80. (It simplifies at least documentation and maintenance. Standardization is sometimes making simplifying choices when nothing functional is lost by making them.)

> only if the first subnet in the end-user IPv6 prefix is used by another internal router, that isn't going to act as a MAP CE.

"Only if", yes, but indeed in this case.
Having never to renumber is better than having to renumber in some cases, and better than having no residual IPv4 service on some subnets.

> renumbering is in any case going to happen in the home,

Not understood.
Renumbering should be avoided if it can (IMHO).

> and we have to design our protocols to deal with it.

> can we just agree to disagree on the V-octet, and not spend any more working group time on it?

Technical debate is finished if:
- You accept that never having to renumber is a useful feature, compared to having to do it in some cases.
- You avoid statements like "renumbering is in any case going to happen in the home" to negate value of renumbering avoidance.

> it would be good if you wrote up a more detailed analysis in a separate draft, so the considerations are kept somewhere.

I will write a comparison table.

RD

---

From: Ole Trøan <[email-masked]>
Date: Mon, 6 Feb 2012 10:37:17 +0100

Remi,

the V-octet and the CNP, have already been discussed on the mailing list, and the design team discussed it with you in person.

the design team made the choice not to incorporate the V octet nor the CNP mechanism in its proposal.

I don't think it is good use of softwire's time to try to convince me yet again that these features are worth adding.

I've made the proposal that we adopts the design team documents as working group documents, as the design team has done what it was chartered to do. and that you write a draft with proposals of what features you want to see added or changed. then the discussion can continue on improving these working group documents.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 6 Feb 2012 18:16:55 +0100

Alain, Yong, Ralph,

 First, a little bit of history is IMHO useful to understand where we are:
 1.  At the Beijing meeting, end of September, I started, with Professor Xing Li, Wojciech Dec, and Congxiao Bao, a convergence effort based on requirements expressed by double-translation and encapsulation proponents respectively (ref www.ietf.org/mail-archive/web/softwires/current/msg02994). 
 2. In early October, Alain then entrusted Ole with the task to lead a team  having "to formulate a unified format to be used either in an encapsulation or double translation mode, for both hub & spokes and mesh models" (www.ietf.org/mail-archive/web/softwires/current/msg03024)
 3. Working on my own, looking for a stateless solution that would be more completely unified than just the address mapping, I found an approach for that, called 4rd-U. (Its reversible "header mapping" uses systematic IPv6 fragment headers, and TCP-checksum neutrality of mapped addresses. Ref draft-despres-softwire-4rd-u-00)
 4. During the Softwire meeting in Taipei, in his report as MAP-team leader, Ole had a slide stating that checksum neutrality would result into "destination spray" (i.e. would break TCP!). Time lacking for a technical challenge of such a claim, this prevented the WG from finding interest in pursuing the 4rd-U approach.  
 5. In the MAP-team meeting that immediately followed that of the WG, Ole obtained a rough consensus that features of the 4rd-U proposal (checksum neutrality and the V octet) would no longer be considered by the MAP team. 
 6. After that, Ole and I having discussed privately, Ole acknowledged on the WG list that his statement against checksum neutrality was technically invalid. 
 7. Some interest for looking more at the 4rd-U solution was then reported to the chairs, and Alain encouraged me to work on a revised 4rd-U draft for the next meeting (ref www.ietf.org/mail-archive/web/softwires/current/msg03296).
 8. On December 29, I then posted tools.ietf.org/html/draft-despres-softwire-4rd-u-02. Following comments I had received, and accepting that some needs weren't satisfied in draft-02, I posted on January 28 draft-03 which has two tunnel variants close to one another (4rd-E for encapsulation, 4rd-H for header mapping).
 9. On January 30, Ole announced to the WG that the 4 related MAP documents were available (ref www.ietf.org/mail-archive/web/softwires/current/msg03328).

 Thus, people involved in the two approaches have clearly done what they were asked to.

 Trying to converge between the two approaches is worth attempting because, as Ole recently wrote: "let us make it clear that these two solutions are solving exactly the same problem, and they solve it in the same fundamental way (A+P). the differences we're talking about here are what whistles, bells (and dongs) we want to add on to the base specification. consider it a buffet, any feature from one of them can be applied to the other."
 Now, the 4rd-U draft is IMHO the best starting point for a specification that suits implementors that didn't participate in the work, because it is self-consistent and avoids redundancy. It is also AFAIK much clearer than the current set of posted MAP document.

 An example of already achieved convergence is a proposal made by Ole.
 (It concerns the "BR rewrite fragmentation" item of his table of www.ietf.org/mail-archive/web/softwires/current/msg03364, i.e. disambiguation of datagram identifications in packets that go from shared-address CEs to the Internet.)   
 - The need to do something has been identified for the first time in the 4rd-U-03 draft.
 - Ole's proposed solution is simpler than that of the draft. (The need is satisfied directly in CEs, rather than left for BRs to satisfy it.)
 Unless a problem would be identified in the mean time, I will adopt Ole's solution in the next 4rd-U version. 

 Naturally, if Ole would agree to it, he would be most welcome as co-author of the upgraded unified specification. 

Best regards,
RD

---

From: Alain Durand <[email-masked]>
Date: Mon, 6 Feb 2012 15:39:46 -0800

Rémi, Ole:

I'll be in Paris this week for v6 world congres, and I'm planning to spend time with the two of you to make progress on this issue.
Hopefully we will have good news for the wg by the end of the week.

  - Alain.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 6 Feb 2012 16:03:46 -0800

I will be in Paris as well; hoping I can join the conversation...

- Ralph

---

From: Ole Trøan <[email-masked]>
Date: Tue, 7 Feb 2012 13:11:15 +0100

Alain,

> Hopefully we will have good news for the wg by the end of the week.

excellent; this is high priority for me, so please let me know a time suitable for yourselves.

cheers,
Ole

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Feb 2012 11:53:45 -0500

Hello Chairs/AD,

I've been following this discussion and believe both 4rd-U and MAP should be
given a fair and impartial evaluation. IMO we should also avoid 'designing
by committee' and mashing everything together just in an effort to please
everybody.

Thanks,

Reinaldo

On 2/6/12 4:03 PM, "Ralph Droms" <[email-masked]> wrote:

>> I'll be in Paris this week for v6 world congres, and I'm planning to spend
>> time with the two of you to make progress on this issue.

---

From: Jacni Qin <[email-masked]>
Date: Wed, 08 Feb 2012 09:00:06 +0800

Re-,

+1

Cheers,
Jacni

On 2/8/2012 12:53 AM, Reinaldo Penno wrote:
> On 2/6/12 4:03 PM, "Ralph Droms"<[email-masked]>  wrote:
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Feb 2012 11:10:24 +0100

> Please, Remi, do build such a table! That would be very useful.

Here is what I got:

   +----+--------------------------------------+-----+-----+-----+-----+
   |    | Feature                              | MAP | 4rd | MAP | 4rd |
   |    |                                      |  -T |  -H |  -E |  -E |
   +----+--------------------------------------+-----+-----+-----+-----+
   |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  |
   |    |                                      |     |     |     |     |
   |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  |
   |    | class                                |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  3 | IPv6 port-based ACLs work for IPv4   |  Y  |  Y  |  N  |  N  |
   |    | packets                              |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  4 | IPv6 web caches work for IPv4        |  Y  |  Y  |  N  |  N  |
   |    | packets                              |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  5 | No constraint on subnet prefixes in  |  N  |  Y  |  N  |  Y  |
   |    | CE sites (V-octet format)            |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  6 | Number of excluded ports is flexible |  Y  |  N  |  Y  |  N  |
   |    | (GMA algorithm, 2 parameters)        |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  7 | Migration from DS routing to         |  N  |  Y  |  N  |  Y  |
   |    | IPv6-only is possible without        |     |     |     |     |
   |    | changing CE addresses and/or         |     |     |     |     |
   |    | prefixes (DMR may apply to CEs)      |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  8 | Automatic support of all protocols   |  N  |  Y  |  N  |  Y  |
   |    | having ports at their usual place    |     |     |     |     |
   |    | and a TCP-like checksum anywhere     |     |     |     |     |
   |    | (checksum neutrality)                |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  9 | IPv4-options supported               |  N  |  N  |  Y  |  Y  |
   |    |                                      |     |     |     | (1) |
   |    |                                      |     |     |     |     |
   | 10 | Datagram reassembly avoided in BRs   |  N  |  Y  |  N  |  Y  |
   |    |                                      | (2) |     | (2) |     |
   |    |                                      |     |     |     |     |
   | 11 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  |
   |    | cannot be confused in destinations   | (2) |     |     |     |
   +----+--------------------------------------+-----+-----+-----+-----+

   (1) Not in draft yet, but decided to be added (trivial to do)
   (2) Not in draft, but could be added if decided

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Feb 2012 10:39:53 +0100

New version, after a discussion with Ole:

   +----+--------------------------------------+-----+-----+-----+-----+
   |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
   |    |                                      |  -T |  -E |  -H |  -E |
   +----+--------------------------------------+-----+-----+-----+-----+
   |  1 | Full Transparency to IPv4 DF bit     |  N  |  Y  |  Y  |  Y  |
   |    |                                      |     |     |     |     |
   |  2 | ISP can impose a Tunnel traffic      |  N  |  Y  |  Y  |  Y  |
   |    | class                                |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
   |    | third-party CPEs                     |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  |
   |    | packets                              |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
   |    | packets                              |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  |
   |    | subnet prefixes in CE sites (V-octet |     |     |     |     |
   |    | format)                              |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  7 | Number of excluded ports is flexible |  Y  |  Y  |  N  |  N  |
   |    | (GMA algorithm, 2 parameters)        |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  8 | Possible migration from DS routing   |  N  |  N  |  Y  |  Y  |
   |    | to IPv6-only routing without         |     |     |     |     |
   |    | changing CE addresses and/or         |     |     |     |     |
   |    | prefixes (DMR may apply to CEs)      |     |     |     |     |
   |    |                                      |     |     |     |     |
   |  9 | BRs need no change for any new       |  N  |  N  |  Y  |  Y  |
   |    | protocol having ports at their usual |     |     |     |     |
   |    | place and TCP-like checksum          |     |     |     |     |
   |    | (checksum neutrality)                |     |     |     |     |
   |    |                                      |     |     |     |     |
   | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  |
   |    |                                      |     |     |     |     |
   | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  |
   |    |                                      |     |     |     |     |
   | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  |
   |    | cannot be confused in destinations   |     |     |     |     |
   |    |                                      |     |     |     |     |
   | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  |
   |    | to support is defined                |     |     |     |     |
   |    |                                      |     |     |     |     |
   | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 |
   +----+--------------------------------------+-----+-----+-----+-----+

---

From: Ole Trøan <[email-masked]>
Date: Thu, 9 Feb 2012 18:23:12 +0100

> New version, after a discussion with Ole:

possible with MAP-{E,T} too, but may require coordination of subnet numbering.
in all solutions will require a different provisioning model.

suggest we rename this to "IPv6 features can be applied to the payload packet"?
(we're talking about applying features in between the translators/tunnel endpoints here).
you could also add a new feature:
 "possible to apply IPv4 features on the payload" which is possible if IPv4 features are enhanced to support offset the tunnel encap header.
so:

| 4.1 | IPv6 features can be applied to the payload packet"  | Y | N | Y | N|
| 4.2 | IPv4 features can be applied to the payload with     | N | Y | N | Y|
|     | "tunnel vision                                  

suggest you rename to "IPv4 to IPv6 communication (single translation) supported"

I don't agree with this wording. actually the MAP interface-id has less constraints, in that it doesn't depend on the V-octet. what about emphasizing the problem V solves?

"Native IPv6 hosts can co-exist with MAP node on the same subnet"
or  "Reserved subnet needed for MAP function"

I also think you need to add:
| N | "New format of interface-id needs to be standardized | N | N | Y | Y |

all mechanisms do support this. this is purely a deployment option in my mind, more than it separates the mechanisms. I would suggest you drop it.
it requires a separate IPv6 prefix purely for the MAP function, and it requires importing IPv4 routing into IPv6.

I don't think that is correct. an implementation would have to verify that the ports is actually in the place the algorithm expects. and it needs to check that the transport protocol uses a TCP-like checksum.
any MAP node MUST be L4 aware.
you could add:

|9.1|New transport protocols can be supported regardless of L4 header format and checksum algorithm| Y | Y | N | N |

right, I would expect this would be added to MAP too.

likewise for this one. so it would be Y all around.

do we typically state the lower limit of the size of tables (e.g. BGP table) in IETF specifications?

I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 |

I also suggest you add the features:

| 15 | Handle IPv4 UDP checksum = 0 | Y | Y | N | Y |
| 16 | Running code                 | Y | N | N | N |

cheers,
Ole

---

From: Xing Li <[email-masked]>
Date: Fri, 10 Feb 2012 11:28:43 +0800

>> New version, after a discussion with Ole:

(1) More clarification should be added for the IPv4 DF bit transparency 
issue, i.e. the advantages versus cost.

(a) MAP-T is almost DF bit transparent, expect a special case which 
4rd-H addresses (the case with DF=1 and MF=1). However, based on the 
experimental data, this kind of packets is about 0.1% of the total 
packets (mainly TCP) and is not representing the production traffic.

(b) The cost to achieve the full transparency to IPv4 DF bit is that the 
IPv6 packets which 4rd-H generates will always contain fragmentation 
headers.  In addition, the middle bits of the IPv6 ID fields in the IPv6 
fragmentation header will contain the IPv4 TOS information.  By my 
understanding, these are changes to the standard of the IPv6 
architecture and careful study for the impact to the current network 
devices (firewall)/end systems should be taken. We should not run into a 
situation that there are packets containing headers look like IPv6 
headers, but not really IPv6 headers according the current standard of 
the IPv6 architecture. If people do need the full transparency to IPv4 
DF bit, use encapsulation.

> suggest you rename to "IPv4 to IPv6 communication (single translation) supported"

(2) More clarification should be added here. I am not sure 4rd-H can 
support single translation.

(a) According to (1), 4rd-H does not perform header translation defined 
by RFC6145.

(b) In the softwire mailing list, it seems that 4rd-H cannot support 
single translation.  See the thread containing 
http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and 
other posts.

(c) If 4rd-H cannot support single translation, then "IPv6 web caches 
work for IPv4 packets" requires special configurations, it cannot do 
IPv6 web caches for non 4rd-H packets.

> | N | "New format of interface-id needs to be standardized | N | N | Y | Y |

(3) The introduction of the V-octet is another change to the standard of 
the IPv6 architecture. We should be very careful and study the impacts 
to the existing network.

> | 16 | Running code                 | Y | N | N | N |

(4) This is a very important point. We need running code and experiments 
to prove a new design.

(5) I would like to see the details of how 4rd-H handles ICMP and ICMP 
error messages. In the softwire mailing list there were some 
discussions. See the thread containing 
http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and 
other posts.Please add

| 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |

I also agree with other comments Ole presented in the mail.

Regards,

xing

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Feb 2012 11:10:40 +0100

> possible with MAP-{E,T} too, but may require coordination of subnet numbering.

Your describing what you have in mind would be useful.
So far I see the 4rd-U approach as the only specified one that is viable.
 
> in all solutions will require a different provisioning model.

Not sure what you mean.
Anything missing in 4rd-U in this respect?

> (we're talking about applying features in between the translators/tunnel endpoints here).

The point being true, I don't see a need to change it.
What you propose is less precise, and IMHO consequently less useful.

> "possible to apply IPv4 features on the payload"

Don't understand what it means in practice.

> which is possible if IPv4 features are enhanced to support offset the tunnel encap header.
> so:
> 

With any interpretation I can imagine of of what you write, I see this as a different point.
OTOH, I acknowledge that there is a point worth analysing about the relationship with single translation.
More about this in my forthcoming answer to Xing.

> I don't agree with this wording. actually the MAP interface-id has less constraints, in that it doesn't depend on the V-octet. what about emphasizing the problem V solves?

I added "addresses" following the technical discussion we had on Wednesday, understanding that it was sufficient for the statement to be true.
Are you negating that current MAP drafts MAY imply a change of subnet prefix or host address in CE sites that assigned them before adding MAP support?
If yes, please explain.

> "Native IPv6 hosts can co-exist with MAP node on the same subnet"

??

> or  "Reserved subnet needed for MAP function"

The table is written so that Y is always positive.

> | N | "New format of interface-id needs to be standardized | N | N | Y | Y |

True, but not an operational feature.

Clarifying that the unused combination of "u" and "g" bits can be used as an escape mechanism is useful for any new Interface ID formats that may prove useful in the future. 4rd-U is only the first instance of that.  

> all mechanisms do support this.

Well, the current MAP draft says:
- "There are three types of mapping rules"
- In a CE, "A MAP IPv6 address (or prefix) is formed from the BMR Rule IPv6 prefix"
I found this confusing, but I am ready to acknowledge that, by making it very clear that a mapping rule can have simultaneously several types, there can be Y in the 4 columns.

A problem will still remain in the hub&spoke case because MAP has "In hub and spoke mode, all traffic MUST be forwarded using the Default Mapping Rule." Then, if some CEs have their MAP IPv6 address (or prefix) derived with this rule, packets sent to them from other CEs will be routed directly to them, the contrary of hub&spoke. 

I suppose that MAP can add the "toBR" bit (bit 79 in 4rd-U) to solve this problem. (I didn't check however, whether this would remain safe without the V octet).

> this is purely a deployment option in my mind, more than it separates the mechanisms.

> I would suggest you drop it.

Once you make clear that a Mapping rule can be both Default and Basic, I would rather restrict its scope to hub&spoke (see above). 

> I don't think that is correct.

Please read the sentence once more, and say exactly which words make it untrue.

> an implementation would have to verify that the ports is actually in the place the algorithm expects. and it needs to check that the transport protocol uses a TCP-like checksum.

The point is "without change". 
(With a change, any solution can be said to have new features.) 
> right, I would expect this would be added to MAP too.

Good.

> likewise for this one. so it would be Y all around.

Good.
As indicated, this table is about current drafts.

> do we typically state the lower limit of the size of tables (e.g. BGP table) in IETF specifications?

Completely different.
ISPs that have many IPv4 prefixes MUST know how many rules to specify in each Domain to make sure all independently acquired CEs can work in mesh topology.
Do you deny that this number is useful?

(BTW, sorry we didn't discuss this point on Wednesday, I had it on a list but skipped it.)

> I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 |

Fortunately you have more substantial points ;-).
(This line is just informational.)

> | 15 | Handle IPv4 UDP checksum = 0 | Y | Y | N | Y |

Could you be more specific about what MAP does for this, separating MAP-T and MAP-E?

> | 16 | Running code                 | Y | N | N | N |

Running code is definitely good, but not sufficient to say that a feature is good to have?
OTOH, we agree that lines 12 an 13 are good to have without running code.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Feb 2012 11:23:21 +0100

Hi Xing,
Good to have you coming in the (unfinished) technical analysis.

I answered to Ole on his remarks, which you support, but not on the following:

You propose to have a line on "IPv4 to IPv6 communication (single translation) supported", wit 

Let me therefore reiterate the wish to see an ISP use case, with its Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem you see.

Regards,
RD

Le 2012-02-10 à 04:28, Xing Li a écrit :
...                                      |     |     |     |     |
> (2) More clarification should be added here. I am not sure 4rd-H can support single translation.
> 
> (a) According to (1), 4rd-H does not perform header translation defined by RFC6145. 
> 
> (b) In the softwire mailing list, it seems that 4rd-H cannot support single translation.  See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts.
> 
> (c) If 4rd-H cannot support single translation, then "IPv6 web caches work for IPv4 packets" requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets.

...

> (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add
> 
...

---

From: Ole Trøan <[email-masked]>
Date: Fri, 10 Feb 2012 15:25:07 +0100

Remi,

> So far I see the 4rd-U approach as the only specified one that is viable.

MAP uses the first subnet of a End-user IPv6 prefix. to deploy a MAP CE behind another IPv6 CE, the only thing required is to route the prefix (/64) used for MAP to this CE. 

both 4rd-u and MAP assume that prefix assignment with multiple routers is solved, and that some other  mechanism exists for provisioning.

I don't see the point of having text in the specification for this use case. it is a deployment option.

> What you propose is less precise, and IMHO consequently less useful.

there are many more features than just ACLs.
you are misleading when stating that the IPv6 ACLs work on IPv4 packets. they don't.

> Don't understand what it means in practice.

a reason for T is to be able to apply "native IPv6 features" in the network. given that there is a feature gap between IPv4 and IPv6 support in existing gear, where IPv4 features are better supported. then an E solution could allow IPv4 features to be applied to tunnel packets. in practice:
    pak->network_start += 40.
    apply IPv4 features to inner packet
    pak->network_start -= 40

> More about this in my forthcoming answer to Xing.

can a T session terminate in a native unchanged IPv6 host? as long as this host has an IPv6 MAP address?
that is single translation. and implies that T packets "leak" into the native network. examples of use cases for this is web caching, captive portals, or just providing IPv4 access to IPv6 only servers.
given the wider scope, your feature name is not sufficient.

> Are you negating that current MAP drafts MAY imply a change of subnet prefix or host address in CE sites that assigned them before adding MAP support?

as I said with a mapping resulting in a 128 bit tunnel end point address, that can be taken out of the first /64 even if this is used by native hosts. the probability of collision is minimal.

> The table is written so that Y is always positive.

yes, I think that a separate /64 prefix or separate /128 address is used for the MAP function is a positive.

> True, but not an operational feature.

your table has non-operational features. the usefulness of the table in my mind, is to identify the differences between MAP and 4rd-u and evaluate features that potentially can be added to MAP.
the purpose of the MAP team, was to do a first pass on that, and in the existing proposals we dropped many proposed features. you re-propose some of them in 4rd-U and all add some news ones. it is fair that those get a fair hearing. I don't think this table is restricted to "operational features"

> Clarifying that the unused combination of "u" and "g" bits can be used as an escape mechanism is useful for any new Interface ID formats that may prove useful in the future. 4rd-U is only the first…

if you did that, then the new mechanism would conflict with 4rd-U.

> I suppose that MAP can add the "toBR" bit (bit 79 in 4rd-U) to solve this problem. (I didn't check however, whether this would remain safe without the V octet).

no, I don't see why the bit 79 would be needed in MAP.
the CE will configure itself with an IPv4 address and port set from the BMR. given that it is in hub and spoke mode it will not install any FMRs, but only a DMR. all traffic not being for itself, will be forwarded using the DMR.

> Once you make clear that a Mapping rule can be both Default and Basic, I would rather restrict its scope to hub&spoke (see above). 

no, two rules are used for this.

> Please read the sentence once more, and say exactly which words make it untrue.

the "no change"

> (With a change, any solution can be said to have new features.) 

you can't do that "without change". that would result using random bits for ports in L4 protocols that has a different layout. given that, you need to check the L4 protocol, and only accept the ones you support. CNP does not make supporting new L4s simpler.

> Do you deny that this number is useful?

yes. the number is a guess. we risk ending up with implementations _only_ supporting the smallest number. as we have little deployment experience that's a bad idea.

> Could you be more specific about what MAP does for this, separating MAP-T and MAP-E?

MAP-E carries the IPv4 packet unchanged and doesn't touch the UDP checksum.
MAP-T rewrites the UDP checksum to a valid IPv6 packet and re-translates it to an IPv4 UDP packet with a checksum.
not transparent, but keeps a valid IPv6 packet inside the domain.

> OTOH, we agree that lines 12 an 13 are good to have without running code.

I'm saying that the best technology, even if it was perfect doesn't "win". running code does.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Feb 2012 18:53:34 +0100

> I don't see the point of having text in the specification for this use case. it is a deployment option.

I plan to have sometime a separate thread on this one, not technically trivial AFAIK.

> there are many more features than just ACLs.

The point being only both true and operationally differentiating, its presence here is AFAIK justified.

> you are misleading when stating that the IPv6 ACLs work on IPv4 packets. they don't.

I wrote "port-based ACLs", never claimed it for all "IPv6 ACLs".

>    apply IPv4 features to inner packet

You may find that the point is minor, but it remains: some deployed products aren't ready yet to do what you suggest yet, and no announced availability date and/or price. 
The point was made at the Beijing meeting, and has not been denied since then, AFAIK.

> given the wider scope, your feature name is not sufficient.

As answered to Xing Li, this point of relationship with single translation deserves IMHO its own thread (not technically trivial AFAIK.

> as I said with a mapping resulting in a 128 bit tunnel end point address,

Not clear what you mean (I find your draft quite unclear as to how Interface IDs of CE destinations are built)  

> that can be taken out of the first /64 even if this is used by native hosts. the probability of collision is minimal.

In any case, a design without collisions is better than one with low probability collisions.

> yes, I think that a separate /64 prefix or separate /128 address is used for the MAP function is a positive.

I see no operational gain compared to what is achieved with the V octet.

> your table has non-operational features.

Which ones?
Maybe header length, which has I would say negligible impact on bandwidth to be offered to customers, but it is only informational, without Y (positive) or N (negative).

> the usefulness of the table in my mind, is to identify the differences between MAP and 4rd-u and evaluate features that potentially can be added to MAP.

That's of course a restricted view on the purpose of this table. 
I made it to help the chairs, and WG participants in general, to analyze operational differences between solutions.

> if you did that, then the new mechanism would conflict with 4rd-U.

4rd-U only uses 0x03 as first Interface-ID octet.
All other values of this octet that have binary 11 in their lower bits can be used for other purposes. 

> no, I don't see why the bit 79 would be needed in MAP.

The explanation is AFAIK in the second paragraph above ("A problem will ... hub&spoke")
Whether it is bit 79 or another is secondary.

> no, two rules are used for this.

The DHCPv6 option doesn't distinguish rule types.
So, if both the BMR and the FMR have a null length IOPv4 prefix, I don't see how the longest match works.

??

> you can't do that "without change". that would result using random bits for ports in L4 protocols that has a different layout. given that, you need to check the L4 protocol, and only accept the one…

If, by mistake of a source, a datagram from the Internet having a port-less L4 is addressed to a shared IPv4 address with a port-less transport layer, it will reach a NAT44 that will discard it. Not a problem AFAIK.

> yes. the number is a guess. we risk ending up with implementations _only_ supporting the smallest number. as we have little deployment experience that's a bad idea.

If CEs are implemented with only 32 rules, I don't see the practical problem.
But, as said in the draft, the WG could easily agree on a larger number, 512 if you wish.
The point is that ISPs MUST know which number does guarantee mesh operation.

> not transparent, but keeps a valid IPv6 packet inside the domain.

Yes, this is a lack of transparency that is avoided in MAP-E and in both 4rd-H and 4rd-E.
A line could be added.

Note also that RFC6145 has:
"Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be translated by the IP/ICMP translator.  However, when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated."

In other words, with double translation, one isn't sure what happens to null-checksum IPv4 packets when 

RD

---

From: Maoke <[email-masked]>
Date: Tue, 14 Feb 2012 20:09:14 +0900

Remi, Ole, and others,

sorry but i follow this quite late due to recent busy work. i would like to
share some of my understandings to this issue.

2012/2/6 Rémi Després <[email-masked]>

> >> Imagine a variant of the SCTP of RFC4960 is introduced where the
> TCP-like checksum MAY be used to facilitate its deployment, say SCTP-bis
> (not a bad idea IMHO, but here just a hypothesis to answer your point).

i understand that Remi's concern is, RFC6145 left an "OPTIONAL" for the
support of the DCCP checksum. this "OPTIONAL" may impact as 1) for the
single translation, DCCP checksum check might fail in the alien protocol
family; 2) for the double translation, there is a risk that the
sender-translator has done the L4 checksum rewrite while the receiver side
doesn't, and thus the DCCP checksum transparency is voilated. the same
concern is applicable for the SCTP, if someday TCP-fashion checksum is
applied too.

if the both sides consistently do not do L4 checksum-rewriting for DCCP,
there is no problem for the end-to-end communication but only the boxes in
IPv6 domains, if they check the L4 checksum to approve the packet
integrity, might drop packets with wrong checksum. it could be a
recommendation if RFC6145 would make the L4 checksum rewriting fixed for
any protocols or make an emphasis on the consistency in configuration,
(i.e., OPTIONAL in the term of domain operation rather than in the term of
equipment making/configuration).

> >>
> >> Upgrading NAT44s to support this SCTP-bis would be trivial (ports as
> the same place as usual can be mapped as usual.
> >
> > my point is that MAP is L4 aware anyway, and has to be modified to
> support any new transport protocol. since code modifications have to be
> made, then having a checksum neutral function at the network layer doesn't
> help much. you still need to change code. L4 rewrite is also more flexible
> in that it will support _any_ checksum algorithm, and most importantly is
> already implemented in every node.
>
> Thus, you continue to negate that 4rd-U would support without any change a
> protocol such as, for example, a SCTP variant using TCP-like checksum
> instead of its CRC32c checksum.
>
> - UDP, TCP, DCCP, SCTP have the same places for port their fields, but
> have their own places for their checksum fields.
> - A solution based on checksum neutrality of IPv6 addresses doesn't need
> to know where checksum fields are placed.

however, dear Remi, the problem is, even we have the checksum neutrality in
address scheme, there are still some problems need to concern:
1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 doesn't and
therefore the checksum rewrite is anyway needed for ICMP; we cannot ensure
that future L4 procotols may definitely have the same checksum as in TCP.
2) in the environment where single translation is also envolved (either
stateless or stateful), L4 checksum rewriting is a MUST because sometimes
there is only one address of the (src, dst)-pair following the
checksum-neutral address scheme. (this is mentioned in RFC6052, giving up
to enforce the checksum-neutrality in the address format, to my knowledge).

therefore, even it is possible that the address scheme could support
checksum neutrallity, the equipment designer must anyway make the module
for L4 rewrite for any well-known L4 protocol (and fortunately it is not a
big coding at all). i understand Ole has the same opinion: as we anyway
have it, we don't need it in the address scheme standard (but it could be a
recommendation for the operators to enable the address-level checksum
neutrality, put in either prefix or interface id, through the address
assignment, in order to help any L4 protocol when its TCP-flavor checksum
rewrite happens not to be considered/implemented).

cheers,
maoke

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Feb 2012 15:34:33 +0100

Le 2012-02-14 à 12:09, Maoke a écrit :

> Remi, Ole, and others,
> 
> sorry but i follow this quite late due to recent busy work. i would like to share some of my understandings to this issue. 
> 
> i understand that Remi's concern is, RFC6145 left an "OPTIONAL" for the support of the DCCP checksum. this "OPTIONAL" may impact as 1) for the single translation, DCCP checksum check might fail in the alien protocol family; 2) for the double translation, there is a risk that the sender-translator has done the L4 checksum rewrite while the receiver side doesn't, and thus the DCCP checksum transparency is voilated. the same concern is applicable for the SCTP, if someday TCP-fashion checksum is applied too.

This is indeed one point.

> if the both sides consistently do not do L4 checksum-rewriting for DCCP, there is no problem for the end-to-end communication but only the boxes in IPv6 domains, if they check the L4 checksum to approve the packet integrity, might drop packets with wrong checksum. it could be a recommendation if RFC6145 would make the L4 checksum rewriting fixed for any protocols or make an emphasis on the consistency in configuration, (i.e., OPTIONAL in the term of domain operation rather than in the term of equipment making/configuration). 
>  
> >>
> however, dear Remi, the problem is,

ANOTHER problem. 
The point just above remains true, right?
 
> even we have the checksum neutrality in address scheme, there are still some problems need to concern:
> 1) ICMPv6 checksum contains pseudo-header like TCP while ICMPv4 doesn't and therefore the checksum rewrite is anyway needed for ICMP; we cannot ensure that future L4 procotols may definitely have the same checksum as in TCP.

ICMP is as subject per se, and dealt with as such.
(ICMP isn't a transport protocol having _port fields at their usual place_)
>  
> 2) in the environment where single translation is also envolved (either stateless or stateful), L4 checksum rewriting is a MUST because sometimes there is only one address of the (src, dst)-pair following the checksum-neutral address scheme. (this is mentioned in RFC6052, giving up to enforce the checksum-neutrality in the address format, to my knowledge).

I have aways acknowledged that L4 update is necessary for single translation, no disagreement.
But here the problem is stateless IPv4 service across IPv6, a different problem where there is no such necessity.

> therefore, even it is possible that the address scheme could support checksum neutrallity, the equipment designer must anyway make the module for L4 rewrite for any well-known L4 protocol (and fortunately it is not a big coding at all).

Coding complexity is not the point (trivial in both cases).
The point is that, where it can be used, checksum neutrality is MORE GENERAL than L4 update.
Besides, but less important, it is simpler as far as the number of specifications it depends on is concerned (no need to know where checksum fields are for different protocols).

> i understand Ole has the same opinion: as we anyway have it,

There can be implementations of BRs that are independent of single translation.
They don't need to know where checksums are placed in various protocols.

> we don't need it in the address scheme standard

One can live with a standard less good than it could be but, since we are working for the future, let's make them as good as we can now.
In any case, this is no excuse to claim that, with checksum neutrality the following is not correct "BRs need no change for any new protocol having ports at their usual place and TCP-like checksum" (DCCP, SCTP if it would acce^t TCP-like checksum, any other.)

> (but it could be a recommendation for the operators to enable the address-level checksum neutrality,

What remains to be seen is what is gained by not having it a MUST while we are specifying a new standard for a new problem.

Cheers,
RD

> put in either prefix or interface id, through the address assignment, in order to help any L4 protocol when its TCP-flavor checksum rewrite happens not to be considered/implemented). 
> 
> cheers,
> maoke

---

From: Maoke <[email-masked]>
Date: Wed, 15 Feb 2012 00:21:55 +0900

2012/2/14 Rémi Després [email-masked]

> But here the problem is stateless IPv4 service across IPv6, a different
> problem where there is no such necessity.
>
>

RFC6052 includes also the double-translation case. i guess operators
wouldn't like to deploy different translators here for single translation
while there for double.

> The point is that, where it can be used, checksum neutrality is MORE

how do you define the "generality"? doing L4 update is a safe choice no
matter if the addresses are checksum-neutral or not.

>
> Besides, but less important, it is simpler as far as the number of
> specifications it depends on is concerned (no need to know where checksum
> fields are for different protocols).
>
>

> One can live with a standard less good than it could be but, since we are
> working for the future, let's make them as good as we can now.
> In any case, this is no excuse to claim that, with checksum neutrality the
> following is not correct "BRs need no change for any new protocol having
> ports at their usual place and TCP-like checksum" (DCCP, SCTP if it would
> acce^t TCP-like checksum, any other.)
>
>
i think making L4 checksum update is a safe choice for standard. once we
have a new L4 protocol, the BR surely need a change to check if this new
protocol is a TCP-checksumed one. at least the BR's code should include the
new protocol number in to the list of checksum-neutrality-compatible.
A better BR needs also to check the packet integrity with ensuring that the
checksum is correct and there a L4 activity is not avoidable. therefore i
do agree with Ole's argument. if i make anything incorrect, please point
out.

best,
maoke

> What remains to be seen is what is gained by not having it a MUST while we
> are specifying a new standard for a new problem.
>
> Cheers,
> RD
>
> put in either prefix or interface id, through the address assignment, in
> order to help any L4 protocol when its TCP-flavor checksum rewrite happens
> not to be considered/implemented).
>
> cheers,
> maoke
>
>
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Feb 2012 16:53:25 +0100

Le 2012-02-14 à 16:21, Maoke a écrit :

> RFC6052 includes also the double-translation case. i guess operators wouldn't like to deploy different translators here for single translation while there for double.
>  
>  
> how do you define the "generality"? doing L4 update is a safe choice no matter if the addresses are checksum-neutral or not.
>  
>  
> i think making L4 checksum update is a safe choice for standard. once we have a new L4 protocol,
> the BR surely need a change to check if this new protocol is a TCP-checksumed one.

1. A key, that probably hasn't been clarified enough so far (thanks for in fact raising it), is the following:
- With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP etc. (see R-22 (3) of the 4rd-U draft).

If, by mistake a remote host sends to a shared IPv4 address a packet whose L4 payload has no ports at their usual places, the packet, if it reaches a CE, will ALWAYS be  discarded there (protocol unknown by the NAT44) => no operational problem. 

This is one more instance where it isn't useful to try and guess what mistakes people might make, and to add specific software for them while tools already exist to detect and signal them. (Keep it simple)

OK?

> at least the BR's code should include the new protocol number in to the list of checksum-neutrality-compatible.

See above.

> A better BR needs also to check the packet integrity with ensuring that the checksum is correct and there a L4 activity is not avoidable.

2. A less good BR in my understanding: more processing for no appreciable gain.

>  therefore i do agree with Ole's argument.

> if i make anything incorrect, please point out.

See above.

Cheers,
RD

---

From: Maoke <[email-masked]>
Date: Wed, 15 Feb 2012 11:15:22 +0900

2012/2/15 Rémi Després <[email-masked]>

>> In any case, this is no excuse to claim that, with checksum neutrality
>> the following is not correct "BRs need no change for any new protocol
>> having ports at their usual place and TCP-like checksum" (DCCP, SCTP if
>> it would acce^t TCP-like checksum, any other.)
>>
>>
> have a new L4 protocol,
> If, by mistake a remote host sends to a shared IPv4 address a packet whose
> L4 payload has no ports at their usual places, the packet, if it reaches a
> CE, will ALWAYS be  discarded there (protocol unknown by the NAT44) => no
> operational problem.
>

MAP should also works for the case where IPv4 addresses are not shared and
there is no NAT44. "protocol unknown" should be detected and discarded at
both CE and BR in their major module instead of the NAT44 part.

>
> This is one more instance where it isn't useful to try and guess what
> mistakes people might make, and to add specific software for them while
> tools already exist to detect and signal them. (Keep it simple)
>

1. as the above, MAP should not depend upon NAT44.

2. on the other hand, even the NAT44 works in front of CE, there is no
NAT44 works between BR and a remote host (not belonging to the MAP domain).
the assumption of "NAT44 discards unknown protocol" only available in the
case where communication is initialized by a client in the CE-delegated
network. be more clarified:

    host.A --- NAT44 --- CE ---- IPv6 domain ---- BR --- IPv4 Internet ---
host.B

(a) A initiates connection to B => ok, that the NAT44 checks protocol
unknown.
(b) B initiates connection to A => BR has to check if L4 protocol is
supported or not.
(c) A initiates communication to B through a UDP or TCP signaling channel
while B reply a connection request on another channel over a new L4
protocol => BR has to check if the new L4 protocol is supported or not.

and in the case of (c), R-22 (3)'s processing looks dangerous -- blindly
deciding where the port is located without looking at the L4 protocol
layout narrows the applicability of the proposal.

however, surely it is not a problem if you state the scope of applicability
of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS BEEN KNOWN
(known by the BR/CE rather than human) as having the same header layout as
well as the same checksum algorithm (without variation).

i don't think MAP standard have nor should have such a limitation. A
MAP-compliant device supports UDP, TCP, DCCP, SCTP today, with the same
logic, and will support any emerging L4 protocol in the future, again with
the same logic. requiring L4 checksum update for any supported protocol
makes it a stable standard, and the checksum update logic is stable for any
protocol. in 4rd-U, however, with the R-22 (3), today it can support UDP,
TCP, DCCP and SCTP-variant(? not sure due to lack of personal knowledge),
while if tomorrow we have a new protocol XXXP:
   a) XXXP has the same layout and same checksum logic, then the 4rd-U
compliant BR should be changed in order it knows that XXXP is also
supported and the logic R-22 (3) is still available;
   b) XXXP is different, then 4rd-U compliant BR should be changed in order
it knows that XXXP is now supported but different logic should be applied.

in either a) and b), the BR should be changed otherwise the XXXP will be
not supported. therefore i still think Ole's argument is not unfair here.

btw, regarding the below "new standard for a new problem", i'd like to
emphasize it is not a new problem as RFC6052 has discussed it. it is an
incorrect understanding to think RFC6052/RFC6145 is designed only for
single translation. since the very beginning of the stateless address
mapping/translation design, the single and double translations have being
considered.

- maoke

> A better BR needs also to check the packet integrity with ensuring that
> the checksum is correct and there a L4 activity is not avoidable.
>
>
>> What remains to be seen is what is gained by not having it a MUST while
>> we are specifying a new standard for a new problem.
>>
>> Cheers,
>> RD
>>

---

From: Washam Fan <[email-masked]>
Date: Wed, 15 Feb 2012 21:34:10 +0800

Hi Maoke,

Just one point. Please see inline.

> while if tomorrow we have a new protocol XXXP:

Please keep in mind both MAP and 4rd-U are transition techniques, from
a long-term perspective, they might disappear before any new L4
protocol invented;)

washam

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Feb 2012 15:45:21 +0100

2012-02-15 à 03:15, Maoke a écrit :

> MAP should also works for the case where IPv4 addresses are not shared and there is no NAT44.

Indeed, in particular for CEs that are assigned IPv4 prefixes.
So does 4rd-H, without identified problem.
 
> "protocol unknown" should be detected and discarded at both CE and BR in their major module instead of the NAT44 part.

I don't think so:
- If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't exclude any protocol in packets sent to this CE.
- If a CE has a shared address, it needs a NAT that the CE informs it the restricted port set. This NAT already has all what is needed to refuse protocols it doesn't understand. 

> 2. on the other hand, even the NAT44 works in front of CE, there is no NAT44 works between BR and a remote host (not belonging to the MAP domain). the assumption of "NAT44 discards unknown protocol" only available in the case where communication is initialized by a client in the CE-delegated network. be more clarified: 
> 
>     host.A --- NAT44 --- CE ---- IPv6 domain ---- BR --- IPv4 Internet --- host.B 
> 
> (a) A initiates connection to B => ok, that the NAT44 checks protocol unknown. 
> (b) B initiates connection to A => BR has to check if L4 protocol is supported or not. 
> (c) A initiates communication to B through a UDP or TCP signaling channel while B reply a connection request on another channel over a new L4 protocol => BR has to check if the new L4 protocol is supported or not. 
> 
> and in the case of (c), R-22 (3)'s processing looks dangerous -- blindly deciding where the port is located without looking at the L4 protocol layout narrows the applicability of the proposal.

Which danger?
On the contrary, avoiding that BRs depend on a list of L4 protocols enlarges their applicability.

> however, surely it is not a problem if you state the scope of applicability of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS BEEN KNOWN (known by the BR/CE rather than human) as having the same header layout as well as the same checksum algorithm (without variation).

I just say (and repeat) that, for shared-address CEs, 4rd-U BRs support WITHOUT MODIFICATION any L4 protocol that has ports at their usual place and a TCP-like checksum. 

> i don't think MAP standard have nor should have such a limitation.

Which limitation?
On the contrary, checksum neutrality eliminates the need for a BR upgrade if a new protocol using conventional ports and TCP-like checksum is introduced.

> A MAP-compliant device supports UDP, TCP, DCCP, SCTP today,

Not SCTP today, for sure.
Also, as I think you know, there is uncertainty concerning DCCP because RFC6145 sec 4.5 says:
"Other transport protocols (e.g., DCCP) are OPTIONAL to support".

> with the same logic, and will support any emerging L4 protocol in the future, again with the same logic. requiring L4 checksum update for any supported protocol makes it a stable standard, and the checksum update logic is stable for any protocol. in 4rd-U, however, with the R-22 (3), today it can support UDP, TCP, DCCP and SCTP-variant(? not sure due to lack of personal knowledge), while if tomorrow we have a new protocol XXXP:
>    a) XXXP has the same layout and same checksum logic, then the 4rd-U compliant BR should be changed in order it knows that XXXP is also supported and the logic R-22 (3) is still available; 

Not AFAIK.
You can check that R-22 (3) does not depend on any L4 protocol (the only protocol that needs to be recognized is ICMP (a layer-3 protocol).

>    b) XXXP is different, then 4rd-U compliant BR should be changed in order it knows that XXXP is now supported but different logic should be applied. 
> 
> in either a) and b), the BR should be changed otherwise the XXXP will be not supported. therefore i still think Ole's argument is not unfair here. 

Let me repeat once more:
If XXXP has (1) the same checksum algorithm, (2) the same port layout (like UDP, TCP, DCCP and SCTP do have), (3) a different layout for the checksum field (as is the case for UDP, TCP, DCCP, SCTP), THEN no new logic is needed in 4rd-H (because of its checksum neutrality). 

I do hope this point will eventually be understood in the WG, rather repeatedly negated.

> btw, regarding the below "new standard for a new problem", i'd like to emphasize it is not a new problem as RFC6052 has discussed it. it is an incorrect understanding to think RFC6052/RFC6145 is designed only for single translation. since the very beginning of the stateless address mapping/translation design, the single and double translations have being considered. 

I have no intention to negate anything about what designers of RFC6052/6145 considered (I wasn't there ;-)).

The problem which IS NEW is how to design a stateless v4/v6 solution that:
- is AS TRANSPARENT to IPv4 as encapsulation, without any restriction or doubt
- yet works with IPv6-only port-based ACLs and IPv6 Web caches.
In my understanding, 4rd-H is indeed such a solution (and is the only one on the table).

Regards,
RD

PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a different subject which deserves a discussion thread with another title.

---

From: Maoke <[email-masked]>
Date: Thu, 16 Feb 2012 10:16:50 +0900

2012/2/15 Washam Fan <[email-masked]>

> a long-term perspective, they might disappear before any new L4

good point! but, ... if they are really transition-able ;) i am not so
optimistic.

on the other hand, the thread is talking on whether BR needs to be changed
or not for new L4 protocol. ;-)

best,
maoke

---

From: Maoke <[email-masked]>
Date: Thu, 16 Feb 2012 11:34:27 +0900

>>> One can live with a standard less good than it could be but, since we
>>> are working for the future, let's make them as good as we can now.
>> If, by mistake a remote host sends to a shared IPv4 address a packet
>> whose L4 payload has no ports at their usual places, the packet, if it
>> reaches a CE, will ALWAYS be  discarded there (protocol unknown by the
>> NAT44) => no operational problem.
>>
>
> there is no NAT44.
> "protocol unknown" should be detected and discarded at both CE and BR in
> their major module instead of the NAT44 part.
>
>
> I don't think so:
> - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't
> exclude any protocol in packets sent to this CE.
> - If a CE has a shared address, it needs a NAT that the CE informs it the
> restricted port set. This NAT already has all what is needed to refuse
> protocols it doesn't understand.
>

what if my NAT has understood XXXP but your CE hasn't? to my understanding,
CE only informs the restricted port set regardless of the protocol.

> layout narrows the applicability of the proposal.
On the contrary, avoiding that BRs depend on a list of L4 protocols
> enlarges their applicability.
>

> however, surely it is not a problem if you state the scope of
> applicability of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS
> BEEN KNOWN (known by the BR/CE rather than human) as having the same header
> layout as well as the same checksum algorithm (without variation).
>
>
> I just say (and repeat) that, for shared-address CEs, 4rd-U BRs
> support WITHOUT MODIFICATION any L4 protocol that has ports at their usual
> place and a TCP-like checksum.
>
> On the contrary, checksum neutrality eliminates the need for a BR upgrade
> if a new protocol using conventional ports and TCP-like checksum is
> introduced.
>
>

it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for
the operation domain, it is not a problem for double translation. if it is
OPTIONAL per device, the uncertainty is a problem where src-translator
makes DCCP checksum rewrite but dst-translator doesn't. (inverse case,
where src translator doesn't make but dst do, is not a problem though.)

>
>
> with the same logic, and will support any emerging L4 protocol in the
> future, again with the same logic. requiring L4 checksum update for any
> supported protocol makes it a stable standard, and the checksum update
> logic is stable for any protocol. in 4rd-U, however, with the R-22 (3),
> today it can support UDP, TCP, DCCP and SCTP-variant(? not sure due to lack
> of personal knowledge), while if tomorrow we have a new protocol XXXP:
> You can check that R-22 (3) does not depend on any L4 protocol (the only
> protocol that needs to be recognized is ICMP (a layer-3 protocol).
>
>    b) XXXP is different, then 4rd-U compliant BR should be changed in
> order it knows that XXXP is now supported but different logic should be
> applied.
>
> If XXXP has (1) the same checksum algorithm, (2) the same port layout
> (like UDP, TCP, DCCP and SCTP do have), (3) a different layout for the
> checksum field (as is the case for UDP, TCP, DCCP, SCTP), THEN no new logic
> is needed in 4rd-H (because of its checksum neutrality).
>

ok, i think we do understand your point but please check. you mean: if
addresses are checksum-neutral, we don't need to have a list of supported
protocol in BR and just let it pass any protocol with the assumption that
it is TCP-layouted/checksumed. if the "any protocol" happens to really have
TCP-layout and TCP-checksum, then things are happy and the addresses have
ensured the checksum validity even without L4 rewrite. if the "any
protocol", unfortunately, happens to have another layout and/or another
checksum, then BR also treat it as it were TCP-layouted/checksumed but let
it fail at the end host or CE. right?

here it is what i said R-22 (3) in 4rd-U is dangerous. it says:

   + If the packet Protocol is not ICMP, bits 0-15 for an
   IPv4 source address, and bits 16-31 for a destination
   address.

well doesn't it mean: even if the protocol has another layout, R-22 (3)'s
BR prefer to ignore the fact, making messy mapped addresses with blindly
assuming the protocol follows the TCP-layout!? (there is no NAT44 before BR
to ensure the "unknown" protocol has been dropped.) i would further point
out that, the messy mapped destination address may navigate your packet in
a wrong direction towards a wrong CE where even the "fail at end" may fail.

therefore i do agree Ole's argument. because we think any protocol should
be certainly supported, or certainly reported as not-supported, rather than
blindly trying a seemingly "universal" logic.

> I have no intention to negate anything about what designers of
> RFC6052/6145 considered (I wasn't there ;-)).
>

NOT AS TRANSPARENT to IPv4 as encapsulation at least in following 2 points:

1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. this
is not a behavior of encapsulation but a behavior of translation.

2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message
will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please note
that RFC6145 Sec 5.2 is a typical behavior of translation rather than
encapsulation. for the encapsulation, the semantics of ICMPv6 message
processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U
draft 03 contains the RFC2473 in the reference list but never cites it in
the main text).

if we say some fields are transparent, that's ok. but if we are talking
about the IP as a whole, TRANSPARENCY implies not only the consistency of
packet header fields but also the behavior of hiding details of the
carrying underlay infrastructure.

best,
maoke

> PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a
> different subject which deserves a discussion thread with another title.
>
> ...
>
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Feb 2012 10:54:45 +0100

Le 2012-02-16 à 03:34, Maoke a écrit 
> what if my NAT has understood XXXP but your CE hasn't? to my understanding, CE only informs the restricted port set regardless of the protocol. 

2 cases:
- If the new protocol has ports at their usual place, and has TCP-like checksum, no problem. "Your CE", as you call it, does forward packets of the new protocol. 
- In other cases, any CE or BR would need needs an update to work, and incompatibilities cold result. 

...
> it depends on the understanding of the "OPTIONAL". if it is OPTIONAL for the operation domain, it is not a problem for double translation. if it is OPTIONAL per device, the uncertainty is a problem where src-translator makes DCCP checksum rewrite but dst-translator doesn't. (inverse case, where src translator doesn't make but dst do, is not a problem though.) 

Optional "for the operation domain" would work only if there would be means to inform CEs of the choice made for the domain.
Such means don't exist, right?

> ok, i think we do understand your point but please check. you mean: if addresses are checksum-neutral, we don't need to have a list of supported protocol in BR and just let it pass any protocol with the assumption that it is TCP-layouted/checksumed. if the "any protocol" happens to really have TCP-layout and TCP-checksum, then things are happy and the addresses have ensured the checksum validity even without L4 rewrite. if the "any protocol", unfortunately, happens to have another layout and/or another checksum, then BR also treat it as it were TCP-layouted/checksumed but let it fail at the end host or CE. right?

Yes.
We are in sync on this point.

> well doesn't it mean: even if the protocol has another layout, R-22 (3)'s BR prefer to ignore the fact, making messy mapped addresses with blindly assuming the protocol follows the TCP-layout!? (there is no NAT44 before BR to ensure the "unknown" protocol has been dropped.) i would further point out that, the messy mapped destination address may navigate your packet in a wrong direction towards a wrong CE where even the "fail at end" may fail.

Still a misunderstanding here.
No new protocol will work for shared IPv4 addresses, be it with MAP or 4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their usual place, and a TCP-like checksum somewhere).
A NAT44 that is coupled with a CE MUST remain operational ONLY for "traditional" protocols.

(Future protocols, if not "traditional", will need IPv6 to work safely, including with shared-IPv4-address CEs.

> therefore i do agree Ole's argument. because we think any protocol should be certainly supported, or certainly reported as not-supported, rather than blindly trying a seemingly "universal" logic. 

1.
I don't know which "Ole's argument" you agree to (making your own points directly would be clearer). 
- In particular, Ole wrote "any A+P solution requires support for L4 protocols to extract ports. L4 checksum rewrite, as well as port extraction will have to be supported for all new L4 protocols."
- The fact is that 4rd-U, because of checksum neutrality, doesn't have to support L4 checksum rewrite. Yet, it is an A+P solution that has no identified operational problem.

2.
4rd-U "certainly" supports All "traditional" protocols, an Echo requests in identified conditions,  and nothing else.
MAP-T is AFAIK uncertain for DCCP.

> 1) 4rd-H packet's Hop Limit is decreased per hop in the IPv6 domain. this is not a behavior of encapsulation but a behavior of translation. 

1.
Well, there remains an inconsistency that I didn't see in the 4rd-U draft(!): 
- "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel traversal is treated in IPv4 as a single-link traversal. Without it, Explicit Congestion Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations, and IPv4 Time to live values progress with the number of traversed IPv6 links."
- Table 2 has:
+---------------------+-----------------------------------+
| IPv4 FIELDS         | VALUES SET AT DOMAIN EXIT         |
+---------------------+-----------------------------------+
                    ...
| Time to live        | Hop limit                         |
                    ...
+---------------------+-----------------------------------+

 Correction should be:
"R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit Congestion Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations."
Thanks for the opportunity to notice this inconsistency.

2.
IPv4 time-to-live of an IPv4 may thus progress by more than one during domain traversal, right, but this isn't a breach to IPv4 end-to-end transparency (the TTL is THE field that always evolve during network traversal). 

> 2) 4rd-U draft, at R-33, states its IPv6-domain-generated ICMPv6 message will be translated to ICMPv4 with the logic of RFC6145 Sec 5.2. please note that RFC6145 Sec 5.2 is a typical behavior of translation rather than encapsulation. for the encapsulation, the semantics of ICMPv6 message processing should be quite different (cf. RFC2473, Sec 8.) (btw, 4rd-U draft 03 contains the RFC2473 in the reference list but never cites it in the main text). 

1. How an IPv6-generated ICMP message is translated into an IPMPv4 message, doesn't belong to "IPv4 transparency".
2. MAP-E has the same need. Otherwise unreachable CEs couldn't be signaled to IPv4 sources, right?

The point remains that 4rd-U is "as transparent to IPv4 as MAP-E". 
This is AFAIK a simple and important fact (it was designed for that). 

> if we say some fields are transparent, that's ok.

> but if we are talking about the IP as a whole, TRANSPARENCY implies not only the consistency of packet header fields but also the behavior of hiding details of the carrying underlay infrastructure.

Agreed.
(But with due understanding of the exception of time-to-live: it always decreases end to end, and more or less depending on peculiarities of traversed infrastructures). 

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Thu, 16 Feb 2012 20:19:21 +0900

2012/2/16 Rémi Després <[email-masked]>

> what if my NAT has understood XXXP but your CE hasn't? to my
> understanding, CE only informs the restricted port set regardless of the
> protocol.
>
>
> 2 cases:
> - If the new protocol has ports at their usual place, and has TCP-like
> checksum, no problem. "Your CE", as you call it, does forward packets of
> the new protocol.
> Optional "for the operation domain" would work only if there would be
> means to inform CEs of the choice made for the domain.

agree. for this point, we'd prefer to propose an update to RFC6145 in order
to clear the uncertainty, if the authors have not other concern we haven't
noticed.

> We are in sync on this point.

good. thanks!

> No new protocol will work for shared IPv4 addresses, be it with MAP or
> 4rd-U BRs, if it isn't a "traditional" protocol (i.e. ports at their usual
> place, and a TCP-like checksum somewhere).

it confuses me. if there is no new protocol, where we have the talking
topic on the *change* of BR? neither MAP nor 4rd-U needs change if there is
no new protocol. if there is new protocol in consideration, how do you
assert such a new protocol surely not work for shared IPv4 addresses unless
it is a "traditional" one? do you mean non-traditional protocol is nonsense
and we have no obligation to consider? or do you mean, new protocol working
with shared IPv4 addresses must be traditional?

> directly would be clearer).

i think i focuses on the point that the "BR needs no change ...".

>
> - In particular, Ole wrote "any A+P solution requires support for L4
> protocols to extract ports. L4 checksum rewrite, as well as port extraction
> will have to be supported for all new L4 protocols."
> - The fact is that 4rd-U, because of checksum neutrality, doesn't have to
> support L4 checksum rewrite. Yet, it is an A+P solution that has no
> identified operational problem.
>
> 2.
> 4rd-U "certainly" supports All "traditional" protocols, an Echo requests
> in identified conditions,  and nothing else.

MAP-T has been in running code and it is not complicated to remove the
uncertainty with changing the OPTIONAL to a definite word, unless there is
something we haven't noticed.

> - "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
> that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel
> traversal is treated in IPv4 as a single-link traversal.
>

right, here the "single-link traversal" causes TTL decreases more than 1.
well, you removed this self-contradictory.

> Without it, Explicit Congestion Notification of [RFC3168] MAY be
> propagated from intermediate IPv6 nodes to IPv4 destinations, and IPv4 Time
> to live values progress with the number of traversed IPv6 links."
>

misunderstanding! please note that ECN being propagated from intermediate
IPv6 to IPv4 is correct even for the mode of encapsulation! because
congestion is a link-wise behavior. RFC3168 Sec 9 discussed this and its
succeeding updates RFC6040 takes a huge effort in order to achieve
compatibility among different processing proposals regarding the potential
inconsistency between the outer header's ECN and inner header's ECN. the
basic operation is: tunnel entry point should copy ECN from inner to outer
header while tunnel exit should copy ECN from outer to inner.

> "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class that
> BRs and CEs MUST set in Tunnel packets.  Without it, Explicit Congestion
> Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to
> IPv4 destinations."
> IPv4 time-to-live of an IPv4 may thus progress by more than one during
> domain traversal, right, but this isn't a breach to IPv4 end-to-end
> transparency (the TTL is THE field that always evolve during network
> traversal).
>

> 1. How an IPv6-generated ICMP message is translated into an IPMPv4
> message, doesn't belong to "IPv4 transparency".
>

"belongs to" or not is only a text gaming. i focus on the behavior: you
stated it is "as encapsulation" and therefore i argue its behavior is not
encapsulation behavior at all.

> 2. MAP-E has the same need. Otherwise unreachable CEs couldn't be signaled

MAP-E applying any existing encapsulation standard such as RFC2473 or GRE
as the packet processing method surely has been ready for that. the same
need has been satisfied without need to define again. it could be emphasize
the RFC2473's ICMPv6-to-ICMPv4 processing is consistent with the semantics
of "virtual link" which the encapsulation contributes to the Internet
architecture.

> The point remains that 4rd-U is "as transparent to IPv4 as MAP-E".

narrow sense transparency, no problem in wording. but i suppose people are
concerning the behavior rather than the wording itself.

> but if we are talking about the IP as a whole, TRANSPARENCY implies not
> only the consistency of packet header fields but also the behavior of
> hiding details of the carrying underlay infrastructure.
>
>
> Agreed.
> (But with due understanding of the exception of time-to-live: it always
> decreases end to end, and more or less depending on peculiarities of
> traversed infrastructures).
>

encapsulation makes underlay as a link-layer, and certainly the TTL only
decreases by 1 if no trouble. decreasing as the same in the underlay
network is the behavior of translation. it exposes the details of the
underlay and therefore not transparent as encapsulation.

best,
maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Feb 2012 19:01:39 +0100

Le 2012-02-16 à 12:19, Maoke a écrit :

> agree. for this point, we'd prefer to propose an update to RFC6145 in order to clear the uncertainty, if the authors have not other concern we haven't noticed. 

Seems good to me.
However, a specification change doesn't ensure that all devices support the change. 
A problem therefore remains.

> it confuses me.

> if there is no new protocol, where we have the talking topic on the *change* of BR? neither MAP nor 4rd-U needs change if there is no new protocol.

Clear.

> if there is new protocol in consideration, how do you assert such a new protocol surely not work for shared IPv4 addresses unless it is a "traditional" one?

Yes, I do suggest that a transition tool such as MAP/4rd shouldn't be modified to support a new protocol that would have been be specified with consciousness that it is difficult to support in NAT44s.

> do you mean non-traditional protocol is nonsense and we have no obligation to consider?

A nonsense, by no means!
Defining new protocols, even with non-TCP checksum, can make a lot of sense, but only in the context of IPv6.

> or do you mean, new protocol working with shared IPv4 addresses must be traditional? 

My point is that any new protocol that should work for hosts having IPv4 shared addresses SHOULD use the TCP-like checksum, yes.
(I use SHOULD instead of MUST because we talk about the future, which is uncertain by nature.)

> MAP-T has been in running code and it is not complicated to remove the uncertainty with changing the OPTIONAL to a definite word, unless there is something we haven't noticed. 

This point has no relationship with the fact that checksum neutrality provides BR support of all L4 protocols using TCP-like checksum.

> - "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets.  In this case, tunnel traversal is treated in IPv4 as a single-link traversal.
> 
> right, here the "single-link traversal" causes TTL decreases more than 1. well, you removed this self-contradictory. 
>  
> Without it, Explicit Congestion Notification of [RFC3168] MAY be propagated from intermediate IPv6 nodes to IPv4 destinations,

> and IPv4 Time to live values progress with the number of traversed IPv6 links."

Note that this part of the sentence no longer appears in the revised R-4 

> misunderstanding! 

> please note that ECN being propagated from intermediate IPv6 to IPv4 is correct even for the mode of encapsulation!

Exactly, where it it applies in 4rd-U (no Tunnel traffic class parameter) it does it for both -H AND -E. 

> because congestion is a link-wise behavior. RFC3168 Sec 9 discussed this and its succeeding updates RFC6040 takes a huge effort in order to achieve compatibility among different processing proposals regarding the potential inconsistency between the outer header's ECN and inner header's ECN. the basic operation is: tunnel entry point should copy ECN from inner to outer header while tunnel exit should copy ECN from outer to inner. 

Right 

> "belongs to" or not is only a text gaming. i focus on the behavior:

> you stated it is "as encapsulation" and therefore i argue its behavior is not encapsulation behavior at all. 

4rd-H IS NOT "encapsulation" (not more than it is "double translation").
The only claim is that it is, end-to end, as transparent to IPv4 packets as encapsulation.

> MAP-E applying any existing encapsulation standard such as RFC2473 or GRE as the packet processing method surely has been ready for that. the same need has been satisfied without need to define again. it could be emphasize the RFC2473's ICMPv6-to-ICMPv4 processing is consistent with the semantics of "virtual link" which the encapsulation contributes to the Internet architecture.

I didn't see this ICMP translation in the BR behavior of the MAP-E draft sec. 5.2, but it certainly can be added.
In any case, this doesn't make 4rd-U less end-to-end transparent to IPv4 than encapsulation.

> narrow sense transparency, no problem in wording. but i suppose people are concerning the behavior rather than the wording itself. 
>  
> encapsulation makes underlay as a link-layer, and certainly the TTL only decreases by 1 if no trouble. decreasing as the same in the underlay network is the behavior of translation.

> it exposes the details of the underlay and therefore not transparent as encapsulation. 

Different view (IMHO, this statement is just playing with words)

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Fri, 17 Feb 2012 12:41:25 +0900

Remi,

up to this message, i think we both have stated our points and have
clarified where we agree to each other where we don't. for some part, even
with the different terminology, we have known what each other are talking
about. it looks i have no further comments for this thread any more. :)

thanks and regards,
maoke

2012/2/17 Rémi Després <[email-masked]>

>>> - If a CE has a shared address, it needs a NAT that the CE informs it
>>> the restricted port set. This NAT already has all what is needed to refuse
> agree. for this point, we'd prefer to propose an update to RFC6145 in
> order to clear the uncertainty, if the authors have not other concern we
> haven't noticed.
>
>
> Seems good to me.
> if there is no new protocol, where we have the talking topic on the
> *change* of BR? neither MAP nor 4rd-U needs change if there is no new
> protocol.
>
>
> Clear.
>
> if there is new protocol in consideration, how do you assert such a new
> protocol surely not work for shared IPv4 addresses unless it is a
> "traditional" one?
>
>
> Yes, I do suggest that a transition tool such as MAP/4rd shouldn't be
> modified to support a new protocol that would have been be specified with
> consciousness that it is difficult to support in NAT44s.
>
> My point is that any new protocol that should work for hosts having IPv4
> shared addresses SHOULD use the TCP-like checksum, yes.
>  therefore i do agree Ole's argument. because we think any protocol
>> should be certainly supported, or certainly reported as not-supported,
>> rather than blindly trying a seemingly "universal" logic.
>>
>>
>> 1.
> This point has no relationship with the fact that checksum neutrality
> provides BR support of all L4 protocols using TCP-like checksum.
>
>
>> propagated from intermediate IPv6 nodes to IPv4 destinations,
>>
>
>
> please note that ECN being propagated from intermediate IPv6 to IPv4 is
> correct even for the mode of encapsulation!
>
>
> Exactly, where it it applies in 4rd-U (no Tunnel traffic class
> parameter) it does it for both -H AND -E.
>
>
> because congestion is a link-wise behavior. RFC3168 Sec 9 discussed this
> and its succeeding updates RFC6040 takes a huge effort in order to achieve
>> "R-4   "Tunnel traffic class", if provided, is the IPv6 traffic class
>> that BRs and CEs MUST set in Tunnel packets.  Without it, Explicit
>> Congestion Notification of [RFC3168] MAY be propagated from intermediate
>> IPv6 nodes to IPv4 destinations."
> network is the behavior of translation.
>
>