Re: [Softwires] Comments on 4rd-u-04
Le 2012-03-13 à 01:59, Maoke a écrit : hi Remi, 2012/3/12 Rémi Després despres.r...@laposte.net Maoke, 1. What you call the cost of IANA authority on the use of V-bit is neither a development nor an operational cost. Once standardization is done, the cost becomes 0. exactly. 2. Isn't it true that MAP addresses must have the u octet, i.e. 0x00, in address bits 64-71? If yes, MAP example addresses you give with 0x02 or 0x03 instead of u, aren't AFAIK valid MAP addresses. oh, yes! i made the typo, falling into the EUI-64 case. MAP cites RFC6052 format for IID, while the latter states: Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero. thanks a lot for pointing out the mistake! the corresponding example should be corrected as: #1. shared ipv4 address take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, PSID=8. MAP (without V-octet): native IPv6: 2001:db8:1234:5678::/64 mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:/128 (as a more-specific) cost: almost none. #2. exclusive ipv4 address 2001:db8:1234:5670::/60, IPv4 address 0xabcde567 MAP (without V-octet): native IPv6: 2001:db8:1234:5670::/60 mapped IPv6: 2001:db8:1234:5670:00ab:cde5:6700:/128 (as a more-specific) cost: almost none. #3. exclusive ipv4 subnet 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f MAP (without V-octet): native IPv6: 2001:db8:1234:5600::/56 mapped IPv6: 2001:db8:1234:5600:00ab:cde5:6000:/128 (as a more-specific) 2001:db8:1234:5610:00ab:cde5:6100:/128 (as a more-specific) ... 2001:db8:1234:56f0:00ab:cde5:6f00:/128 (as a more-specific) If no, please explain what I missed. thanks a lot! 3. You say that aggregation doesn't make sense in 4rd-u, e.g. with the following example: - native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit - mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit But the right choice for the second line is: - mapped IPv6: 2001:db8:1234:5670:3000::/72 2001:db8:1234:5670:0300::/72, right? ;-) Right ;-). Thus, longest match does the job. exactly. however, my point is: as the longest-match can do the job with V octet or without it, why don't we directly use the version without it? That's a very different question, answered in sec 4.4 (6) of the draft: NOTE: 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. For this, the V octet has its u and g bits of xref target=RFC4291/ both set to 1. This differs from u = 0, reserved for local-scope Interface IDs, and also differs from u = 1 and g= 0, reserved for unicast Interface IDs using the EUI-64 format. Bits other than u and g, are proposed to be 0, giving V = 0x03. With the V octet, IPv6 packets can be routed to the 4rd function within a CE node based on a /80 prefix that no native-IPv6 address can contain. The V octet can also facilitate maintenance by the parameterless distinction it introduces between Tunnel packets and native-IPv6 packets. A tunnel packet has at least one of its IPv6 addresses having the V octet. Cheers, RD - maoke (What you describe is what might have applied if we had kept the maxPsid feature. But, as you may recall, we abandoned it unanimously in Taipei.) Cheers, RD Le 2012-03-12 à 11:51, Maoke a écrit : 2012/3/12 Rémi Després despres.r...@laposte.net Hi, Washam, Thanks for your detailed questions and comments. Answers and further comments in line. Le 2012-03-11 à 10:48, Washam Fan a écrit : Hi, Eventually I get a chance to review this version and have some major comments and questions as below. 1. Relationship with MAP, MAP-T, MAP-E. I thought, MAP was expected to be a generic algorithm for stateless mapping IPv4 addresses to IPv6 addresses and vice versa. I thought, MAP would apply to MAP-T, MAP-E as well as 4rd-u. The point is that 4rd-u unifies not only the address format for -T and -E, but also the header format so that a single standard becomes sufficient. The 4rd-U technique for this was presented in Taipei, but it didn't arise interest in the MAP team. Design of 4rd-u had then to become autonomous. But draft 4rd-u-04 doesn't mention MAP draft. 4rd-u is proposed as an alternative to the 2-standards approach of MAP. It therefore needs only needs a historical reference to MAP, which is done in sec. 8. And I see the mapping rules stuff in the draft overlapped with MAP. Confused. I thought, 4rd-u is competing with MAP-T and MAP-E to some extend. Would you mind expaund on what benefits 4rd-u can gain exclusively? Ideally, there would be a seperate section or even a seperate draft
Re: [Softwires] Draft 4rd-u-05 is available
Remi, discussion on R-16 of Sec 4.7: R-16: If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC0792]. This packet MUST contain the first 8 octets of the discarded-packet IP payload. now the ICMPv6 error message contains the payload as the header-mapped IPv6 PDU of the discarded packet. right? so does 4rd-U CE or BR translates this ICMPv6 payload to ICMPv4 payload as RFC6145 does? does 4rd-U applies the checksum adjustment algorithm between ICMPv6 and ICMPv4 here, as the RFC6145 does? (for ICMP, the CNP doesn't help) if it does, you'd better cite RFC6145 here. if it doesn't, please specify. If the CE or BR has a global IPv4 address, this address MUST be used as source of this packet. Otherwise, the unspecified address 0.0.0.0 SHOULD be used as this source. let me draw an example for that: A --- CE (IPv6 domain; router R1 here) BR (IPv4 Internet; router R2 here)--- B 1. consider ICMPv6 error happens at R1 original IPv4 packet at A, sent to B: +-+--+ | IPv4| payload | | hdr, H1 | P1 | +-+--+ CE translates (precisely speaking, header-maps) it to: ++--+ | IPv6 | payload | | header, H2 | P1 | ++--+ R1 found a error for this IPv6 packet, it generates an ICMPv6 report: +++---+-+ | IPv6 | ICMPv6 | IPv6 | payload (truncated to | | header, H3 | hdr, C1| header, H2| fit in min IPv6 MTU),P2 | +++---+-+ \___ ___/ V as the ICMPv6 error message body this message feedbacked to CE, who will translate it to: +-+++--+ | IPv4| ICMPv4 | IPv4 | truncated| | hdr, H5 | hdr, C2| hdr, H4| payload, P3 | +-+++--+ |- 8 octet -| \__ __/ V as the ICMPv4 error message body it is clear that 4rd-U address mapping is applied for H1 - H2 - H4 H3 has the source address of R1 while the destination address as the CE. then, CE's (or BR's for the case of B -- A) global IPv4 address or 0.0.0.0 will be used in H5, right? first of all, the 0.0.0.0 might be a wrong choice. Unspecified Address represents either a host not yet having gained an IPv4 address on the LOCAL network or an application listening on any addresses of a host. packet with 0.0.0.0 might be dropped by any intermediate routers of current implementations. ICMPv6 Type = 1 and Code = 0 (Destination unreachable, No route to destination) MUST be translated into ICMPv4 Type = 3 and Code = 0 (Destination unreachable, Net unreachable). ICMPv6 Type = 1 and Code = 0 (Time exceeded, Hop limit exceeded in transit) MUST be translated into ICMPv4 Type = 11 and Code = 0 (Time exceeded, Time to live exceeded in transit). for C1 - C2 translation, i have the following comments: 1) here 4rd-U uses the CE's global IPv4 address (i think global refers to a non-shared one, right?) to represent all the error generator inside in the IPv6 domain. this surely fits a tunnel behavior that attempts to treat the delivery from CE to BR as a link, and therefore the error is responded by the link's end point. 2) however, if this is treated as a tunnel, both ICMPv6 hop-limit exceeded and ICMPv6 unreachable node should be translated as ICMPv4 destination unreachable (Type = 3) host unreachable (Code = 1), because it should indicates the link problem of the tunnel. 3) translating ICMPv6 Hop Limit Exceeded to ICMPv4 Time Exceeded is a typical behavior of path participant rather than a tunnel. the difference of the tunnel and the path participant is: the latter consumes the TTL per physical hop. for example, if we set TTL = 32 in H1, tunneling means from A to B communication may succeed as long as (A---CE) + (BR---B) doesn't exceed 30 hops and CE---BR is well connected; while current 4rd-U means from A to B communication may succeed only when total numbers of intermediate routers doesn't exceed 31. this is why typical tunneling solutions initialize the out-header's IPv6 Hop Limit to 255. when routing loop happens in the IPv6 domain and Hop Limit is consumed out, the link is considered broken. 2. consider ICMPv4 error happens at R2: R2 sees original IPv4 packet at A, sent to B: +-+--+ | IPv4| payload | |
[Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Reinaldo, all, I read the updated version of draft-penno-softwire-sdnat. I like this new version. Below some questions for clarification: (1) draft-penno is converging to what is documented in draft-cui-softwire-b4-translated-ds-lite: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassignhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.bajko-pripaddrassign]. Besides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoordhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.tsou-pcp-natcoord] for one-time port-set allocation. o DHCPv6: the DHCPv6 protocol should be extended to support port-set allocation [I-D.boucadair-dhcpv6-shared-address-optionhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.boucadair-dhcpv6-shared-address-option]. o IPCP: IPCP should be extended to carry the port-set. [RFC6431http://tools.ietf.org/html/rfc6431] gives an example. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/13 Rémi Després despres.r...@laposte.net Le 2012-03-13 à 03:18, Maoke a écrit : 2012/3/12 Rémi Després despres.r...@laposte.net Le 2012-03-12 à 10:21, Maoke a écrit : hi Remi, 2012/3/12 Rémi Després despres.r...@laposte.net 2012-03-12 04:09, Maoke: ... btw, BR also depends upon NAT44 to deal with the unknown protocol, right? if so, may i say your statement BR will support them without needing an update is a proposition actually not existing? because NAT44 won't support them without any update. right? Not right. Only CEs that need to support a new protocol are concerned: - If a shared address server supports a new protocol, it can be reached via an unchanged BR. - If a client using a new protocol tries to reach a shared-address CE that doesn't support this protocol, the client will be returned an error message by the destination NAT44. thanks a lot for the clarification! take an example: A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4 Internet)--- B now A and B are supposed to use a new protocol other than known TCP/UDP/etc. my understanding: B -- A 1. BR just passes the new protocol without any concern. 2. CE's NAT44 module would say this is not supported and a 'destination unreachable with port unknown' ICMP message is returned to B. As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message should be, more precisely, protocol unreachable. thanks for the precise description. Everything OK. A -- B 1. CE's NAT44 module directly say destination unreachable with port unknown ICMP message to A. Presumably also protocol unreachable, but this remains a NAT44 matter. 4rd isn't involved. is the above what you mean? when NAT44 module DOESN'T support the new protocol, things are working while we have no the problem about the change at all for the time being. then let's consider the case where the NAT44 module has been updated to support the new protocol. i understand BR passing all protocols can be survived if and only if the new protocol follows the TCP-layout for the destination port and the TCP-checksum, right? The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. - maoke then you made a limitation (#1) to the NAT44 module of the CE: even if the NAT44 has supported a new protocol not following TCP layout/checksum, this support MUST be disabled in the 4rd-U environment; otherwise, BR may behave wrong when making the mapped IPv6 addresses while the NAT44 would still try to translate with the new protocol rather than dropping an error message because it has known it. right? To me this looks like a far fetched theoretical problem, with no consequence in practice. I said far fetched because: - For shared-address CEs, only protocols that use ports at their usual place and the TCP checksum algorithm are in scope (H6 of comparison tables). With them, there is never anything to disable. - For non-shared address CEs, MAP-T needs updates for all newly supported protocols (including an existing one such as UDP Lite). Like MAP-E, 4rd works for all layer-4 protocols, never needing any update. to me, new protocols following TCP-layout and checksum are a far fetched theoretical problem too, with no consequen in today's practice. i mean, it is unfair when you state the 4rd-U pros you emphasize that BR needs no change with some new protocols, but when we say some other new protocols you say that's far fetched theoretical problem! OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate DCCP or not is a real problem, and so is the fact that it doesn't support UDP Lite, another already existing protocol. i understand RFC6145 said OPTIONAL supporting DCCP just because it was considered less critical at that point of writing (may the authors give an explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, with the same reason. implementation and operation can follow the RFC6145 logic to deal with any L4 protocols. Non-documented reasons were what they were, but consequences should not depend on them. on the other hand, it is easy to update RFC6145 or just making a suggestion anywhere, like a FYI on double-translation behavior of RFC6145, with clarifying DCCP *optional* support should be consistent throughout the domain and clarifying other unmentioned L4 protocol processing should follow the protocol's checksum logic that is specified. i don't see it is necessary to enforcing the address-level checksum neutrality rather than such a simple update or implementation/deployment guidance. Different view on practical consequences of the TBD update or
Re: [Softwires] Draft 4rd-u-05 is available
Hi Behcet, Please see in line. Le 2012-03-12 à 23:09, Behcet Sarikaya a écrit : Hi Remi, My quick comments: editorial on abstract: - The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). remove: for this. Better still have a sentence like: 4rd specifies a protocol mechanism to support Pv4 via a service provider's (SP's) IPv6 network without maintaining per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). - To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. It is not customers but it is CPE or CEs, right? - 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145) replace of with with Editorial improvements can be done later, but thanks for your suggestions. As regards customer, this word seems to me good enough in an abstract (BTW, the word on which are based CPE and CE acronyms). Technical: I don't understand NAT64+ discussion in this draft (it has been added in -04). Why do you need it? It came as a result of the discussion on 464XLAT in v6ops (= copy sent to Cameron Byrne). What is achieved by 464XLAT is AFAIK that, in dual-stack-capable nodes (DS nodes), IPv4-only applications can reach IPv4-only servers via NAT64s. If a DS node is 4rd-capable, and is in a Domain where it has no public IPv4 address (even shared) but where there is a 4rd-capable NAT64 (called a NAT64+), it does all what it does with 464XLAT, but with an improved IPv4 transparency (DF, ICMPv4, DCCP, UDP Lite ...). In NAT64, IPv6 packet is not created by CE but by the host with the help of DNS64. So far, the NAT64 doesn't know how packets are created. A NAT64+ recognizes IPv6 packets that were created to tunnel IPv4 packets, and takes, for them, advantage of better IPv4 transparency. Where is DNS64 in your draft, except for a reference to RFC 6147 which is a bogus reference. Right, this reference isn't needed. Thanks. (NAT64s always go with DNS4s in the IPv4/IPv6 framework of RFC6144, but this isn't a 4rd matter.) NAT64 helps IPv6 only hosts to communicate with IPv4 only servers over an IPv6 network. Indeed, but it also helps DS hosts attached to IPv6-only networks to reach IPv4-only servers, e.g. with BIH. So it has almost nothing to do with 4rd. Nothing to do with 4rd... until 4rd includes a way to improve IPv4 transparency of NAT64s for hosts that are DS (upgrading them to NAT64+). One thing you can do is to say that NAT64 could be colocated with 4rd BR if Pref64 of NAT is chosen to match 4rd prefix. In that case you need to add support for RFC6145 stateful packet translation as well as the NAT state in 4rd BRs. Not in 4rd BRs as defined, only in nodes that colocate BRs and NAT64s. Is this what you would like to do? Maybe I missed something. Hope the above is clarifying. Kind regards, RD Regards, Behcet On Mon, Mar 12, 2012 at 9:56 AM, Rémi Després despres.r...@laposte.net wrote: Hello, all, An updated version of draft-despres-softwire-4rd-u is now available at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05 Differences with -04 include: - DHCPv6 options are now specified - various errors and typos are corrected - some clarifications are added, following received questions and comments - the CE-behind-CPE use case has been revised (mix of CEs behind CPEs and within CPEs) - An editor's note has been added, following a WG-ML discussion, about an additional Mapping-rule parameter that might be needed to assign privileged ports to to some shared-address CEs. - Document layout has been adjusted as a result of other modifications. - the authors list has been completed. Questions and comments are most welcome. Regards, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. Thanks for this info. RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states DS-Lite so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? = if they are the same the answer is easy (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: = BTW we need a better definition of deterministic. My proposal is it means the mapping follows an algorithm (and it is the case on the SD-CGN, BTW not on the SD-CPE). (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite
I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). I agree. GMA is defined here, btw - http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0 2#section-4.1 Cheers, Rajiv -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Francis Dupont Sent: Tuesday, March 13, 2012 12:56 PM To: mohamed.boucad...@orange.com Cc: Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno- softwire-sd...@tools.ietf.org Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4- translated-ds-lite In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states DS-Lite so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? = if they are the same the answer is easy (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: = BTW we need a better definition of deterministic. My proposal is it means the mapping follows an algorithm (and it is the case on the SD-CGN, BTW not on the SD-CPE). (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Francis, Thanks for your reply. Please see inline. On Wed, Mar 14, 2012 at 12:55 AM, Francis Dupont francis.dup...@fdupont.frwrote: In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) [Qiong] Thanks for clarification. It seems this is not mentioned when to adopt and how to process the second NAT in current version of sd-nat. But still, I would prefer a solution without double-NAT. (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the ICMP processing in section 10. And we have verified that it works fine in all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states DS-Lite so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) [Qiong] I still think it is deployment-specific. For operators who perfer to deploy PCP solution, it is nature for them to adopt PCP-base or PCP-extension (pcp-natcoord). For operators who would like to deploy DHCPv4-over-IPv6, port-range can be assigned in this way. Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? = if they are the same the answer is easy (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: = BTW we need a better definition of deterministic. My proposal is it means the mapping follows an algorithm (and it is the case on the SD-CGN, BTW not on the SD-CPE). (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). [Qiong] Since it is a stateless solution, I also prefer the GMA algorithm which has been discusses widely in the WG. Best wishes Qiong Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
2012/3/14, Francis Dupont francis.dup...@fdupont.fr: In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) However, the draft seems give people impression there is only one NAT at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is responsible for decapsulation and IPv4 package validation. Did I miss something? BRs Gang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/13 Rémi Després despres.r...@laposte.net 2012-03-13 12:02, Maoke : 2012/3/13 Rémi Després despres.r...@laposte.net ... The 4rd mechanism is for protocols that have ports at their usual place (all existing protocols that have ports have them at the same place, even if using another checksum algorithm like SCTP). may you have a check on the statement of all existing protocols again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP. I missed this one. None of the proposed stateless solutions supports it, but it remains that you are right: it has ports at a different place. alright. so 4rd-U doesn't not support all existing transport protocol either. but i suppose you may make an update in the 4rd-u-06 so that a new if...else... is added the port pick-up logic, and surely the CNP is not a problem for RDP because the old version (RFC908) has 32bit checksum but not involving pseudo-header while the newer version (RFC1151) changed to use TCP-checksum. no big deal but only needs a new patch to the draft. but this is not my point. my point is: there must be something we don't know (non omnia possumus omnes). even we have gone through the RFCs, there might be some other proprietary L4 protocols, or experimental protocols. even they are minority, i don't think ignoring their existance in our solution fits the spirit of the Internet. it might be argued that NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may makes his own NAT44, either attached to the CE or separated. if 4rd-U respects such an effort, it should state currently blahblabla L4 protocols are supported. the similar statement applies to the RFC6145 or MAP as well. i somehow am hard to accept words like far fetched theoretical problem. the L4-recalculate is a generic, architectural solution, surely needing codes for every L4 protocol. but this generality in architecture makes RFC6145 or MAP-T equipment be easily enhanced to support anything new with the same logic. but for the 4rd-U BR, it looks to me we cannot have the unified logic for all (even limited to existing and well-known) L4 protocols. only my 2 cents. maoke Thanks for this info. RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
