? 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
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
