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

[Rémi Després <[e-mail]>]

Le 2012-02-10 à 15:25, Ole Trøan a écrit :

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

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


> 
>>> in all solutions will require a different provisioning model.
>> 
>> Not sure what you mean.
>> Anything missing in 4rd-U in this respect?
>> 
>>>> |    |                                      |     |     |     |     |
>>>> |  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).
>> 
>> The point being true, I don't see a need to change it.
>> What you propose is less precise, and IMHO consequently less useful.
> 
> 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".

> 
>>> you could also add a new feature:
>>> "possible to apply IPv4 features on the payload"
>> 
>> 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

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.


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

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


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



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



>>> I also think you need to add:
>>> | N | "New format of interface-id needs to be standardized | N | N | Y | Y |
>> 
>> True, but not an operational feature.
> 
> 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.


> 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 instance of that.
> 
> 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. 
 

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


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


>>> 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.
>> 
>> Please read the sentence once more, and say exactly which words make it untrue.
> 
> the "no change"

??


>>> 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 |
>> 
>> The point is "without 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.

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.
 

>>>> |    |                                      |     |     |     |     |
>>>> | 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.
>> 
>> Good.
>> 
>>>> |    |                                      |     |     |     |     |
>>>> | 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.
>> 
>> Good.
>> As indicated, this table is about current drafts.
>> 
>>>> |    |                                      |     |     |     |     |
>>>> | 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?
>> 
>> 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?
> 
> 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.

 
>> (BTW, sorry we didn't discuss this point on Wednesday, I had it on a list but skipped it.)
>> 
>>> 
>>>> |    |                                      |     |     |     |     |
>>>> | 14 | Minimum IP header length             |  40 |  60 |  48 |  60 |
>>>> +----+--------------------------------------+-----+-----+-----+-----+
>>> 
>>> I suggest you change this to "Minimum packet overhead" | 20 | 40 | 28 | 40 |
>> 
>> Fortunately you have more substantial points ;-).
>> (This line is just informational.)
>> 
>>> I also suggest you add the features:
>>> 
>>> | 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?
> 
> 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.

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



> 
>>> | 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.
> 
> I'm saying that the best technology, even if it was perfect doesn't "win". running code does.
> 
> cheers,
> Ole
>