Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Le 2012-03-15 à 10:29, Maoke a écrit : 2012/3/15 Maoke fib...@gmail.com 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:02, Maoke a écrit : 2012/3/15 Rémi Després remi.desp...@free.fr Maoke, Let's try, once more, to understand each other. If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is AFAIAC a positive result of our discussion): a) Such a CE can communicate with an IPv6-only host including in DCCP. b) The same would apply to UDP lite if MAP-T would also require UDP-lite translation. c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as permitted by RFC6145). d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. If we don't agree on this, there is still something to be clarified between us. surely do not. RFC6146 clearly states: The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification. I said If RFC614... would be modified to also impose DCCP translation = I take the point that you are not interested in that, but I don't think there was a contradiction. OK? it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here. more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no interwork between NAT64 who has been modified with the NAT64 who has not. incorrect? The full sentence was: If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. I assumed an RFC6145 complying node can talk to a NAT64, right or not? (A NAT64 talking to another NAT64 was part of what I wrote!!!) RD on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? maoke RD - maoke If we agree, I have nothing else on this point. Regards, RD If, as you suggest, 2012-03-15 02:04, Maoke: 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:46, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net ... Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. 1. I agree that, between CEs and BRs, there can be no problem for DCCP (provided the draft is completed to this effect). The comparison table was explicitly made with existing drafts, and intended to be updatable. 2. The MAP-T draft is also claimed to allow communication between IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in the domain that are using IPv4-mapped IPv6 address. In this case, AFAIK, the backward compatibility problem exists Thought? surely it does not exist. that statement applies to the MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same deployment of equipments should support double-translation, single-translation, and native IPv6 accesses simultanenously. that's one of the points of the MAP-T. - maoke To be even more precise, H6 of the comparison table can be: For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place i actually think the original text is fine. For shared IPv4 addresses is not needed for 4rd-U, to my understanding, nor needed to MAP-T. Will see what to do, then, when changes to the MAP-T draft concerning DCCP are known. RD maoke Does this cover the point? RD ;-) maoke 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
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:22, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:02, Maoke a écrit : 2012/3/15 Rémi Després remi.desp...@free.fr Maoke, Let's try, once more, to understand each other. If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is AFAIAC a positive result of our discussion): a) Such a CE can communicate with an IPv6-only host including in DCCP. b) The same would apply to UDP lite if MAP-T would also require UDP-lite translation. c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as permitted by RFC6145). d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. If we don't agree on this, there is still something to be clarified between us. surely do not. RFC6146 clearly states: The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification. I said If RFC614... would be modified to also impose DCCP translation = I take the point that you are not interested in that, but I don't think there was a contradiction. OK? it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here. OK, we are now in sync on this point :-). on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? On this new subject, could you be more precise on what you mean by stateful checksum validity? i mean i didn't understand the how the stateful NAT64 benefits from CNP. maoke RD maoke RD - maoke If we agree, I have nothing else on this point. Regards, RD If, as you suggest, 2012-03-15 02:04, Maoke: 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:46, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net ... Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. 1. I agree that, between CEs and BRs, there can be no problem for DCCP (provided the draft is completed to this effect). The comparison table was explicitly made with existing drafts, and intended to be updatable. 2. The MAP-T draft is also claimed to allow communication between IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in the domain that are using IPv4-mapped IPv6 address. In this case, AFAIK, the backward compatibility problem exists Thought? surely it does not exist. that statement applies to the MAP-T-compliant equipments, when it is used as a IPv4-to-IPv6 single translator or as an native IPv6 router. same deployment of equipments should support double-translation, single-translation, and native IPv6 accesses simultanenously. that's one of the points of the MAP-T. - maoke To be even more precise, H6 of the comparison table can be: For ISPs that don't provide all CE nodes, and for shared IPv4 addresses, DCCP and UDP-Lite are supported, as well as future protocols using the TCP checksum algorithm and ports at the same place i actually think the original text is fine. For shared IPv4 addresses is not needed for 4rd-U, to my understanding, nor needed to MAP-T. Will see what to do, then, when changes to the MAP-T draft concerning DCCP are known. RD maoke Does this cover the point? RD ;-) maoke 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
[Softwires] 4rd-u tunnels and stateful NAT64s
Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... i didn't understand the how the stateful NAT64 benefits from CNP. The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm) RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] 4rd-u tunnels and stateful NAT64s
Le 2012-03-15 à 10:59, Rémi Després a écrit : Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... i didn't understand the how the stateful NAT64 benefits from CNP. The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm) Oops. This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary). Sorry for having hastily added this sentence. RD 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] 4rd-u tunnels and stateful NAT64s
Le 2012-03-15 à 11:45, Maoke a écrit : i understand NAT64 makes translation between arbitrary IPv6 address to arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 address. in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP. That's no the case at all(!). A NAT64+ is a *backward compatible* extension of NAT64 (everything that worked before still works completely unchanged). The draft says: NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address format. Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for addresses that actually are 4rd CE addresses. RD - maoke 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:59, Rémi Després a écrit : Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... i didn't understand the how the stateful NAT64 benefits from CNP. The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm) Oops. This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary). Sorry for having hastily added this sentence. RD 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
Le 2012-03-15 à 11:40, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:29, Maoke a écrit : 2012/3/15 Maoke fib...@gmail.com 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:02, Maoke a écrit : 2012/3/15 Rémi Després remi.desp...@free.fr Maoke, Let's try, once more, to understand each other. If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is AFAIAC a positive result of our discussion): a) Such a CE can communicate with an IPv6-only host including in DCCP. b) The same would apply to UDP lite if MAP-T would also require UDP-lite translation. c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as permitted by RFC6145). d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. If we don't agree on this, there is still something to be clarified between us. surely do not. RFC6146 clearly states: The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification. I said If RFC614... would be modified to also impose DCCP translation = I take the point that you are not interested in that, but I don't think there was a contradiction. OK? it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here. more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no interwork between NAT64 who has been modified with the NAT64 who has not. incorrect? The full sentence was: If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. I assumed an RFC6145 complying node can talk to a NAT64, right or not? Just referring to: DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet Is this excluded? RD you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not right that RFC6145 complying node can talk to a NAT64. let's see the details: model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145 translator --- B because A would be translated by NAT64 to an arbitrary IPv6 address, A', which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translator cannot handle it statelessly for any end-to-end communication. the box in front of B should be another NAT64, and as i said previously, no problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the other doesn't support, it drops DCCP. no case of asymmetrically processed but end-to-end deliverable DCCP here. - maoke (A NAT64 talking to another NAT64 was part of what I wrote!!!) RD on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? maoke RD - maoke If we agree, I have nothing else on this point. Regards, RD If, as you suggest, 2012-03-15 02:04, Maoke: 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:46, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net ... Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. 1. I agree that, between CEs and BRs, there can be no problem for DCCP (provided the draft is completed to this effect). The comparison table was explicitly made with existing drafts, and intended to be updatable. 2. The MAP-T draft is also claimed to allow communication between IPv4-only, as well as any IPv6 enabled end hosts, to native IPv6-only servers in the domain that are using IPv4-mapped IPv6 address. In this case, AFAIK, the backward compatibility problem
Re: [Softwires] 4rd-u tunnels and stateful NAT64s
2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 11:45, Maoke a écrit : i understand NAT64 makes translation between arbitrary IPv6 address to arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 address. in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP. That's no the case at all(!). A NAT64+ is a *backward compatible* extension of NAT64 (everything that worked before still works completely unchanged). The draft says: NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address format. this phrase is not understood yet. do you mean using 4rd-IPv6-address format for stateful translation service? please draw an example of A --- B communication as i did for clarification. Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for addresses that actually are 4rd CE addresses. we need to make sure if the NAT64s make both src and dst addresses checksum-neutral. i cannot imagine what the use case is. please specify! - maoke RD - maoke 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:59, Rémi Després a écrit : Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... i didn't understand the how the stateful NAT64 benefits from CNP. The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm) Oops. This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary). Sorry for having hastily added this sentence. RD 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] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Re-, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : jeudi 15 mars 2012 12:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite This is a deployment issue. You have 3 variants of DS-Lite CPEs: a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite. You want to be able able to accommodate all 3 variants from the same AFTR. Re-Nating instead of dropping ensure that if a subscriber uses a variant b) when he is provisioned to use port restricted, then traffic still flows. Med: This is deployment-specific. The behaviour to follow when a port-restricted device issues port out of its allocated range should be IMO SP specific and can not be dictated by the specification. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance? 1) - we would have to define the DHCP port option. Not difficult but same amount of work as defining a new ICMP type. 2) - with the ICMP message, the ISP can change the port range without having to wait for the lease time of the DHCP option to expire. Med: Changing the size of the port range is part of planned operations. With DHCP, an SP can change the port range much in advance. This is nothing something which can be done without advanced planning. I don't see an advantage of ICMP here. This allows for more flexibility in micro-managing ports. Med: This is also doable with DHCP and PCP by tweaking the Lease and the Lifetime. 3) - if we use a DHCP option, the client has to proactively ask for it. If it does not, it will think it has the full IP address. That leads to situations that may be difficult to debug, as the customer will not understand why some TCP session works and some don't, the root cause being that the CPE does not have any feedback from the NAT in the AFTR Med: This doable with existing ICMP messages. Nothing prevent the AFTR to drop the packet and send back an ICMP Destination Unreachable message Code 3 Port unreachable error or Code 13 Communication administratively prohibited. 4) - so we'll need a new ICMP message anyway to signal the CPE that something is wrong if/when it sends packets outside of the range. Med: No need to define a new ICMP message for this. Why not using e.g. ICMP Type 3 Code 13? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 11:40, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:29, Maoke a écrit : 2012/3/15 Maoke fib...@gmail.com 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:02, Maoke a écrit : 2012/3/15 Rémi Després remi.desp...@free.fr Maoke, Let's try, once more, to understand each other. If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is AFAIAC a positive result of our discussion): a) Such a CE can communicate with an IPv6-only host including in DCCP. b) The same would apply to UDP lite if MAP-T would also require UDP-lite translation. c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as permitted by RFC6145). d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. If we don't agree on this, there is still something to be clarified between us. surely do not. RFC6146 clearly states: The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification. I said If RFC614... would be modified to also impose DCCP translation = I take the point that you are not interested in that, but I don't think there was a contradiction. OK? it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here. more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no interwork between NAT64 who has been modified with the NAT64 who has not. incorrect? The full sentence was: If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. I assumed an RFC6145 complying node can talk to a NAT64, right or not? Just referring to: DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet what is RFC6145-host?? (seeing you have corrected the v4net with v6net) if it is a host connected to an IPv6 network, it is the case of single NAT64, where we have the problem of interwork? - maoke Is this excluded? RD you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not right that RFC6145 complying node can talk to a NAT64. let's see the details: model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145 translator --- B because A would be translated by NAT64 to an arbitrary IPv6 address, A', which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translator cannot handle it statelessly for any end-to-end communication. the box in front of B should be another NAT64, and as i said previously, no problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the other doesn't support, it drops DCCP. no case of asymmetrically processed but end-to-end deliverable DCCP here. - maoke (A NAT64 talking to another NAT64 was part of what I wrote!!!) RD on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? maoke RD - maoke If we agree, I have nothing else on this point. Regards, RD If, as you suggest, 2012-03-15 02:04, Maoke: 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:46, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net ... Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the 4rd-U. 1. I agree that, between CEs and BRs, there can be no problem for DCCP (provided the draft is completed to this effect). The comparison table was explicitly made with existing drafts, and intended to be updatable. 2. The MAP-T draft is also claimed to allow communication between
Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd
Le 2012-03-15 à 14:52, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 11:40, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:29, Maoke a écrit : 2012/3/15 Maoke fib...@gmail.com 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:02, Maoke a écrit : 2012/3/15 Rémi Després remi.desp...@free.fr Maoke, Let's try, once more, to understand each other. If we assume that MAP-T CEs (and BRs) now MUST translate DCCP (which is AFAIAC a positive result of our discussion): a) Such a CE can communicate with an IPv6-only host including in DCCP. b) The same would apply to UDP lite if MAP-T would also require UDP-lite translation. c) If a MAP-T CE communicates via a NAT64 (which is based on RFC6145, i.e. with DCCP optional), DCCP is broken if the NAT64 doesn't translate DCCP (as permitted by RFC6145). d) If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. If we don't agree on this, there is still something to be clarified between us. surely do not. RFC6146 clearly states: The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification. I said If RFC614... would be modified to also impose DCCP translation = I take the point that you are not interested in that, but I don't think there was a contradiction. OK? it is not yet modified. with the current statement of RFC6146, the current equipment doesn't support DCCP. if it is modified, the update may state mandatory imposement for DCCP. i don't see any problem here. more clearly speaking: stateful NAT64, i think, only needs to be done once in a delivery, therefore either the DCCP is supported or it is not. there's no interwork between NAT64 who has been modified with the NAT64 who has not. incorrect? The full sentence was: If RFC6146 (NAT64) and/or RFC6145 would be modified to also impose DCCP translation, nodes complying with modified versions and those complying with previous versions wouldn't be guaranteed to interwork for DCCP. I assumed an RFC6145 complying node can talk to a NAT64, right or not? Just referring to: DS-RFC6145-host --(v4net) -- NAPT64 -- IPv4 Internet what is RFC6145-host?? E.g. a host with BIH (RFC6535) or with 464XLAT, i.e. one that supports IPv4 applications and is attached to an IPv6-only network. Clear enough? (seeing you have corrected the v4net with v6net) if it is a host connected to an IPv6 network, it is the case of single NAT64, where we have the problem of interwork? See above. RD - maoke Is this excluded? RD you mean the stateful NAT64-ed IPv4 host (let's call it A) having access to an IPv4 host (let's call it B) behind a stateless RFC6145 translator, mapped to IPv4-converted IPv6 address in the IPv6 domain. if so, it is not right that RFC6145 complying node can talk to a NAT64. let's see the details: model: A ---(IPv4 network)--- NAT64 (stateful) ---(IPv6 cloud)--- RFC6145 translator --- B because A would be translated by NAT64 to an arbitrary IPv6 address, A', which is not an IPv4-converted one either in MAP or in RFC6052, the RFC6145 translator cannot handle it statelessly for any end-to-end communication. the box in front of B should be another NAT64, and as i said previously, no problem in interwork. if one NAT64 supports DCCP, it adjusts the checksum; if the other doesn't support, it drops DCCP. no case of asymmetrically processed but end-to-end deliverable DCCP here. - maoke (A NAT64 talking to another NAT64 was part of what I wrote!!!) RD on the other hand, i cannot understand how the CNP helps stateful checksum validity. may you please to clarify? maoke RD - maoke If we agree, I have nothing else on this point. Regards, RD If, as you suggest, 2012-03-15 02:04, Maoke: 2012/3/14 Rémi Després despres.r...@laposte.net Le 2012-03-14 à 10:46, Maoke a écrit : 2012/3/14 Rémi Després despres.r...@laposte.net ... Changing DCCP support from optional to mandatory in RFC6145 isn't backward compatible (an upgraded node isn't guaranteed to interwork with a non upgraded node). the CE/BR specified RFC6145-compliant might be a problem but MAP-T is still in development. if we state to enforce DCCP mandatorily rather than optional in MAP-T, a MAP-T-compliant CE/BR won't has the backward compatible problem. to this extend, MAP-T is at the same kick-off line of the
Re: [Softwires] 4rd-u tunnels and stateful NAT64s
Le 2012-03-15 à 14:47, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 11:45, Maoke a écrit : i understand NAT64 makes translation between arbitrary IPv6 address to arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 address. in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP. That's no the case at all(!). A NAT64+ is a *backward compatible* extension of NAT64 (everything that worked before still works completely unchanged). The draft says: NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address format. this phrase is not understood yet. do you mean using 4rd-IPv6-address format for stateful translation service? Yes (but, s said, only for CE nodes that are 4rd capable (with the advantage of better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NAT64). please draw an example of A --- B communication as i did for clarification. Here is an example scenario: v4appli-BIH . = AB NOK (because, according to RFC6535, BIH uses RFC6145) A1 | :(v6net)- NAT64+ ---(IPv4 Internet)--- Server |UDP-lite UDP-lite v4Appli-4rdCE --' capable B A2 = A-B OK Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for addresses that actually are 4rd CE addresses. we need to make sure if the NAT64s make both src and dst addresses checksum-neutral. Correct, iff the host address has the V octet. i cannot imagine what the use case is. please specify! Hope the picture above helps. RD - maoke RD - maoke 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:59, Rémi Després a écrit : Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... i didn't understand the how the stateful NAT64 benefits from CNP. The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm) Oops. This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary). Sorry for having hastily added this sentence. RD 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] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
On Mar 14, 2012, at 2:34 PM, Francis Dupont wrote: In your previous mail you wrote: 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? = yes, the SD-CGN (the SD-AFTR with DS-Lite) runs a second NAT but only on port (vs. address and port) and following algorithm (aka stateless). This 2nd NAT was the case in sdnat-01. This has changed in sdnat-02, where the SD-CPE pre-shape IPv4 traffic with both address port, so the SD-AFTR does only decapsulation and ACL check. No NAT is done at all in the SD-AFTR. - Alain. ___ 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: Med: Why you need an IPv4 address to run PCP? An implementation example would be as follows: * At bootstrap of the CPE, once an AFTR is discovered, use the Plain IPv6 PCP mode and the new opcode and options defined in http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 to retrieve an IPv4 address and set of port. = the retrieval of the external address is a function which was explicitely put out of PCP by the WG, for the second you'd like to use an extension which was never discussed. To finish there is a difference between discussing about getting the IPv4 address or getting it with other parameters as port ranges, and my comment is only about the first problem. Regards francis.dup...@fdupont.fr PS: I should add another dimension: do we want a solution for DS-Lite or a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs? ___ 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: Med: The PCP case has been demoed. = My comment is about PCP without any extension. In the second demonstration scenario, the CPE requested several sets of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and draft-zhou-softwire-b4-nat-02). = so this doesn't apply. Regards francis.dup...@fdupont.fr PS: we already have a configuration protocol, it is named DHCP. ___ 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: [Qiong] We also have implemented and demoed in IETF 81th. Please refer to http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in Appendix section. = same: my comment is about the base PCP for port range discovery. 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
In your previous mail you wrote: 1) - we would have to define the DHCP port option. Not difficult but same amount of work as defining a new ICMP type. = is it a joke? DHCP has an extension mechanism, not ICMP. 2) - with the ICMP message, the ISP can change the port range without having to wait for the lease time of the DHCP option to expire. = I don't understand the argument: - there is no lease time for an option - when the ISP change the port range it raises an ICMP error for the first packet which falls outside the new range - when the CPE receives the ICMP error it refreshes the port range info So the mechanism doesn't rely in the info being carried in the ICMP. Note this doesn't solves 2 cases where the ICMP can't help: - when the port range is in fact the ICMP echo ID range - when the port range is extended 3) - if we use a DHCP option, the client has to proactively ask for it. If it does not, it will think it has the full IP address. = there are many ways to solve this, for instance the server can refuse to give an IP address or recognize the CPE as being not SD-CPE capable, etc. 4) - so we'll need a new ICMP message anyway to signal the CPE that something is wrong if/when it sends packets outside of the range. = ICMPv4 administratively prohibited (no need for a new message). The advantage of the DHCP option is that the CPE does not need to send the packet with src port 0 at regular intervals, this is all taken care by the DHCP machinery. IMHO, this does not outweight the issues mentioned above, especially 3) 4). = port 0 is invalid so will be likely drop sooner than expected. I don't even believe the ICMP stuff of draft-penno-softwire-sdnat could work in a lab, so in the real world... 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
In your previous mail you wrote: I failed to see how Stateless DS-Lite is different from B4 translated DS-lite. We need to first understand what sd-NAT is trying to solve, then decide whether it is needed or not. = I agree and IMHO they have the same issue: the per-CPE port range is far too easy to track from the Internet side. IMHO the port restricted CPE is a good idea (it should be deployable in most existing CPEs without changing a bit to kernels) but CGN should provide an algorithmic (including the identity) port translation to shuffle CPE port ranges. We can easily define a method in the B4 translated DS-lite draft. We have few on the table (i.e. dhcpv4 over v6 transport, dhcpv6, radius, pcp). We can ask the WG to decide which one should be in the base spec. This is how RFC5959 was written. Alternatively, we can do what RFC6333 does. RFC6333 doesn't have any provision method defined except referring to RFC6334. = I agree on the principle but we should answer to a question first: do we want a mechanism for DS-Lite only or a mechanism applicable to DS-Lite, NAT44 and any other IPv4 CGN? I need use cases. We don't have any issue using dhcp to manage ip address, I fail to see why we need a different method to manage port-set. = me too. Also, if the ISP suddenly changes the port range, what happens to the existing sessions? The CPE should close all the existing sessions or wait until the sessions are done? = I had the same question and there are two solutions: a smooth hard to implement and a rude easy to implement, beginning with the second: - flush the whole context (your first case) - kill only connections which are no longer valid (there is nothing to do for them and you can be lucky...) To wait is not an option because they are already blocked by the CGN. Case 2, sd-aftr must keep track of the ports and don't assign them to another user until the sessions are done. This sounds adding load to the aftr. = this is incompatible with port ranges and the fact the lifetime of a session is potentially unbound. So there is nothing smooth/ user-friendly you can do on the SD-CGN other than never restrict assigned port ranges. port assignment is so important, why not use ds-lite instead? = perhaps to try to make port reassignment of a lower order of annoyance than address reassignment? 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
In your previous mail you wrote: +1 Re-, Please see inline. (I cut here: too long and unreable with not-ASCII characters, quoted-printable silly coding and long lines) Regards francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] 4rd-u tunnels and stateful NAT64s
2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 14:47, Maoke a écrit : 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 11:45, Maoke a écrit : i understand NAT64 makes translation between arbitrary IPv6 address to arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 address. in other words, we cannot limit NAT64 stateful service only serve those IPv6 addresses with CNP. That's no the case at all(!). A NAT64+ is a *backward compatible* extension of NAT64 (everything that worked before still works completely unchanged). The draft says: NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address format. this phrase is not understood yet. do you mean using 4rd-IPv6-address format for stateful translation service? Yes (but, s said, only for CE nodes that are 4rd capable (with the advantage of better IPv4 transparency between CEs and NAT64+ than between RFC6145 and NAT64). please draw an example of A --- B communication as i did for clarification. Here is an example scenario: v4appli-BIH . = AB NOK (because, according to RFC6535, BIH uses RFC6145) A1 | :(v6net)- NAT64+ ---(IPv4 Internet)--- Server |UDP-lite UDP-lite v4Appli-4rdCE --' capable B A2 = A-B OK yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, if the not support means passing-it-through without checksum adjustment, A -- B is fine because neither BIH nor NAT64+ does nothing with the L4, right? B -- A is a question mark, if we use the NAT64+ which does nothing with the L4 checksum, it is also not a problem. however, if we use, as you mentioned before, an UDP-Lite-aware update of RFC6146, that may updates the checksum while the BIH doesn't know that. my point here is: what is the use case with the details of addressing? if and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 address to serve B for the communications, A1 BIH or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't such a address pool for B, things will fail because only one among src and dst is checksum-neutral. Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for addresses that actually are 4rd CE addresses. we need to make sure if the NAT64s make both src and dst addresses checksum-neutral. Correct, iff the host address has the V octet. 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from others. 2. even with the V-octet, do you mean B's IPv4 address also translated (by the NAT64+) to a CNP-and-V-containing IPv6 address? if 2 is true, why you use stateful NAT64+ here for B rather than a stateless one? if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for B's communications, and such a case results only A's mapped address is checksum-neutral, and thus anyway L4 adjustment is needed. if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 address pool in use. 3. RFC6535 states, explicitly, Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180] (but the above technical discussion can omit this for the time being). - maoke i cannot imagine what the use case is. please specify! Hope the picture above helps. RD - maoke RD - maoke 2012/3/15 Rémi Després despres.r...@laposte.net Le 2012-03-15 à 10:59, Rémi Després a écrit : Maoke, Thanks for this question. This subject being new, I take it on a new thread. 2012-03-15 10:38, Maoke: ... i didn't understand the how the stateful NAT64 benefits from CNP. The point is that if a NAT64 is upgraded to support 4rd-u tunnels (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. Any protocol that this NAT64 supports is then supported e2e for 4rd-u CEs These CEs need not being dependent on which NAT64 supports which protocols. Note that the NAT64 doesn't need to have CNP code. It just happens that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 payloads are the same for all protocols that have ports at the same place as TCP/UDP/..., and the same checksum algorithm) Oops. This is only true for the IPv6 host address. To construct an IPv6 address when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. (This is to maintain the property that that middleboxes can treat tunnel packets as valid IPv6 packets. Not a big deal, but necessary). Sorry for having hastily added this sentence. RD RD ___ Softwires
Re: [Softwires] 4rd-u tunnels and stateful NAT64s
on the other hand, may i suggest not to term 4rd tunnel anymore? it confuses. i emphasized it is NOT a TUNNEL to the common understanding at all (but it seems you never?seldom respond to this point, nor to the ICMP issue details. ) - maoke ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-01.txt
Hi Authors, For section 5.3, I think 2 things should be explicitly stated. 1. hairpinning should be supported on the 4over6 concentrator 2. when 4-in-6 packets received, the inner ipv4 src ip address should be checked against outter ipv6 src ip to see if they are match. (Actually, this should be mentioned in security consideration section) Thanks, washam 2012/3/12 internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Public IPv4 over IPv6 Access Network Author(s) : Yong Cui Jianping Wu Peng Wu Chris Metz Olivier Vautrin Yiu L. Lee Filename : draft-ietf-softwire-public-4over6-01.txt Pages : 12 Date : 2012-03-12 When the service provider networks are upgraded to IPv6, IPv4 connectivity will still be demanded by network users, at least in the recent future. This draft proposes a mechanism for end hosts or networks in IPv6 access networks to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. The bi-directionality of end-to-end communication is achieved by allocating public IPv4 addresses to end hosts/networks. This mechanism is an IPv4 access method for network users in IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.txt ___ 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] I-D Action: draft-ietf-softwire-public-4over6-01.txt
Hi Washam, Good points. Will add them in the next version. 2012/3/16 Washam Fan washam@gmail.com: Hi Authors, For section 5.3, I think 2 things should be explicitly stated. 1. hairpinning should be supported on the 4over6 concentrator 2. when 4-in-6 packets received, the inner ipv4 src ip address should be checked against outter ipv6 src ip to see if they are match. (Actually, this should be mentioned in security consideration section) Thanks, washam 2012/3/12 internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Public IPv4 over IPv6 Access Network Author(s) : Yong Cui Jianping Wu Peng Wu Chris Metz Olivier Vautrin Yiu L. Lee Filename : draft-ietf-softwire-public-4over6-01.txt Pages : 12 Date : 2012-03-12 When the service provider networks are upgraded to IPv6, IPv4 connectivity will still be demanded by network users, at least in the recent future. This draft proposes a mechanism for end hosts or networks in IPv6 access networks to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. The bi-directionality of end-to-end communication is achieved by allocating public IPv4 addresses to end hosts/networks. This mechanism is an IPv4 access method for network users in IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-01.txt ___ 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
