Remi, >> 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 | > > (1)It is AFAIK also a "Y" for 4rd. > (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. >> | E-mode: Support for IPv4 | Y | N | >> | options | | | > > (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). indeed, part of the smorgasbord of features the working group can choose between. >> | T-mode: MF bit and TOS bits | N | Y | >> | transparency | | | >> | 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. 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) >> | 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. indeed. >> | Interface-id | RFC6052 | V octet | >> | MAP traffic identified by | Address/prefix | Interception of | >> | | | V octet | > > (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:* >> | 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). 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. >> | Fragment forwarding on BR | N | Y | >> | without reassembly | | | >> | Shared fragmentation id space | N | Y | >> | 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. >> | 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? 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. >> | Complete IPv6 address / | Y | N | >> | prefix | | | > > (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). >> | Provisioned with DHCP | Y | Y | >> +-------------------------------+----------------+------------------+ >> >> Table 1: A+P comparison > cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
