Re: [Softwires] MAP and 4rd - Feature comparison table

[Xing Li <[e-mail]>]

? 2012/2/10 1:23, Ole Trøan ??:
>> 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  |

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


>>    |    |                                      |     |     |     |     |
>>    |  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                     |     |     |     |     |
> possible with MAP-{E,T} too, but may require coordination of subnet numbering.
> in all solutions will require a different provisioning model.
>

>>    |    |                                      |     |     |     |     |
>>    |  4 | IPv6 port-based ACLs work for IPv4   |  Y  |  N  |  Y  |  N  |
>>    |    | packets                              |     |     |     |     |
> 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
>
>>    |    |                                      |     |     |     |     |
>>    |  5 | IPv6 web caches work for IPv4        |  Y  |  N  |  Y  |  N  |
>>    |    | packets                              |     |     |     |     |
> 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.

>>    |    |                                      |     |     |     |     |
>>    |  6 | No constraint on host addresses or   |  N  |  N  |  Y  |  Y  |
>>    |    | subnet prefixes in CE sites (V-octet |     |     |     |     |
>>    |    | format)                              |     |     |     |     |
> 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 |
>
>

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

>>    |    |                                      |     |     |     |     |
>>    |  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)      |     |     |     |     |
> 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.
>
>>    |    |                                      |     |     |     |     |
>>    |  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)                |     |     |     |     |
> 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 |
>
>>    |    |                                      |     |     |     |     |
>>    | 10 | IPv4-options supported               |  N  |  Y  |  N  |  N  |
>>    |    |                                      |     |     |     |     |
>>    | 11 | Datagram reassembly avoided in BRs   |  N  |  N  |  Y  |  Y  |
> right, I would expect this would be added to MAP too.
>
>>    |    |                                      |     |     |     |     |
>>    | 12 | Packet IDs from shared-address CEs   |  N  |  Y  |  Y  |  Y  |
>>    |    | cannot be confused in destinations   |     |     |     |     |
> likewise for this one. so it would be Y all around.
>
>>    |    |                                      |     |     |     |     |
>>    | 13 | The number of rules CEs must be able |  N  |  N  |  Y  |  Y  |
>>    |    | to support is defined                |     |     |     |     |
> do we typically state the lower limit of the size of tables (e.g. BGP table) in IETF specifications?
>
>>    |    |                                      |     |     |     |     |
>>    | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 |
>>    +----+--------------------------------------+-----+-----+-----+-----+
> 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 |

(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



> cheers,
> Ole
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>