Re: [Softwires] [v4tov6transition] 6a44 MTU issues
Fred and Washam, I reacted too fast to previous remarks when I proposed to modify the accepted IPv6 MTU in 6a44 draft. If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could receive them in fragmented IPv4 datagrams. This would be contrary to the objective of simplicity (datagram reassembly would have to be include in 6a44 clients) and to the objective of security (a new door would be open to dos attacks). No change on this point will therefore appear in the next version of the draft. Some additional explanations may be appropriate, but preferably after a consensus on what has to be said. Then the MTU issue of IPv6 in IPv6 tunnels that Fred underlines remains as is. If the PMTU of such a tunnel is unknown, or known to be less than 1280+40, tunnel endpoints have to tunnel 1280-octets external packets in two pieces, using a fragmented IPv6 datagram for this. Reassembly at the other end is then necessary. It can be facilitated if the tunnel is treated as only one flow, with packets in general kept in sequential order. Regards, RD Actually, the 6a44 specification should, instead of 1280, require IPv4 MTU - 28 octets, both for hairpinning and traversal cases. How can you be sure that IPv4 PMTUD will work in the traversal case? In the to-host direction, because the ISP network is all what is left to traverse before reaching the CPE. In what you call the to-host direction, any ICMPv4 returned from the ISP network might not have enough information for stateless translation to ICMPv6. 1. Could you be more specific? Do yout see a significant difference with what happens with 6to4, In the from host direction, one can't be sure, but doesnt' need to. If a smaller PMTU is encountered further downstream, a PTB ICMPv6 error message will be returned from there. In the from-host direction, any ICMPv4 returned from the ISP network might not be delivered to the tunnel endpoint due to NAT filtering, 2. Then the IPv6 service is somewhat damaged concerning fault diagnosing, like the underlying IPv4 service. But at least packets that should be delivered are delivered. and might not have enough information for stateless translation to ICMPv6. 3. Same as 1. above. In the to-host direction, because the ISP network is all what is left to traverse before reaching the CPE. In what you call the to-host direction, any ICMPv4 returned from the ISP network might not have enough information for stateless translation to ICMPv6. I should also say, any ICMPv4 returned from within the end user network (where MTUs might not be so well managed) might not be delivered to the tunnel endpoint in the ISP network. 4. Same as 2. above. (Since IPv4 fragments rather than returning packet-too-big ICMP messages, this cannot concern MTUs). Yet, there remains another problem with the replacement of 1280 by IPv4 MTU - 28 (I proposed it too quickly) because it creates risks of fragmentation ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Ted, The version which passed the Softwire LC is http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-04 which included both name and IP address options. After IESG review, 05 has been published but this version has significant changes. We are at least two service providers who are asking for the need to roll back to 04. If text is needed to justify the need of the name option, for sure we can help. Cheers, Med -Message d'origine- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : mardi 12 octobre 2010 15:50 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Ullio Mario; Chairs Dhc; Softwire Chairs; Softwires; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed On Oct 11, 2010, at 10:42 PM, mohamed.boucad...@orange-ftgroup.com wrote: Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. I'm confused. The current version of the draft is the -05 version, which makes no mention of FQDNs. You seem to be discussing the -04 version. Presumably the -05 version is the one that's meant to be published, so why are you discussing the -04 version? If the name option is needed, then the right thing to do is to issue a new draft. Since the draft would be substantially changed, and in a way that's contrary to the comments from the DHC working group, this would need to be re-reviewed by the DHC working group, and would need a new last call in the Softwires working group. It would be entirely inappropriate for such a substantial change to be made during IESG review without further review by the DHC and Softwires working groups, and without another last call. You would certainly need to explain the use case for the Name option--what value it adds that is missing from the address option. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] 6a44 updated version (draft-despres-softwire-6a44-01)
Hi all, Version -01 of the 6a44 draft has just been posted (www.ietf.org/id/draft-despres-softwire-6a44-01.txt) It includes correction of a substantial bug in Figure 3, an some clarifications. Thanks to all those who helped to improve it. Regards, RD --- Internet Engineering Task Force R. Despres Internet-Draft RD-IPtech Intended status: Standards TrackB. Carpenter Expires: April 15, 2011Univ. of Auckland S. Jiang Huawei Technologies Co., Ltd October 12, 2010 Native IPv6 Across NAT44 CPEs (6a44) draft-despres-softwire-6a44-01 Abstract Most CPEs should soon be dual stack, but a large installed base of IPv4-only CPEs is likely to remain for several years. Also, with the IPv4 address shortage, more and more ISPs will assign private IPv4 addresses to their customers. The need for IPv6 connectivity therefore concerns hosts behind IPv4-only CPEs, including such CPEs that are assigned private addresses. The 6a44 mechanism specified in this document addresses this need, without limitations and operational complexities of Tunnel Brokers and Teredo to do the same. 6a44 is based on an address mapping and on a mechanism whereby suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via a stateless 6a44 server function operated by their Internet Service Provider. With it, IPv6 traffic between two 6a44 hosts in a single site remains within the site. Except for IANA numbers that remain to be assigned, the specification is intended to be complete enough for running codes to be independently written and interwork. ... Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3. 6a44 IPv6 Address Format . . . . . . . . . . . . . . . . . . . 6 4. Address Mappings and Encapsulations . . . . . . . . . . . . . 8 5. MTU considerations . . . . . . . . . . . . . . . . . . . . . . 10 6. Host Acquisition of IPv6 Addresses and their Lifetimes . . . . 10 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Despres, et al. Expires April 15, 2011 [page 2] ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] DHCP option for DS-lite
Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only the IP address option in place. The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should be dealt with differently. Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this. David, Alain - The authors made a significant change to draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on IESG review and input from the dhc WG. The -05 rev is getting de facto review now, but you'll need to determine WG consensus for the changes in the -05 rev. - Ralph If you have a strong opinion that the decision of the authors is the wrong one, please speak up now. This window for comments will end in 7 days, on 10/19. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
On Fri, Oct 08, 2010 at 05:36:48PM +0200, mohamed.boucad...@orange-ftgroup.com wrote: If there is a real issue with defining two DHCPv6 options (which I don't see), The problem of defining two options that convey the same configuration point is a problem we call aliasing. Section 6 (Avoid Aliasing) of draft-ietf-dhc-option-guidelines [1] is dedicated to discuss it, and concludes with the advice to choose one natural format for the option. In summary, it causes implementation confusion when the configuration value for one knob is present in multiple places in the packet - a resolution algorithm must therefore be defined. You could say that one of the IESG criticisms of the AFTR domain name option was that the normative language to enforce this hierarchy is heavy, and unlikely to actually be observed by casual implementers. It creates complication, and our experience is that complication creates problems. Worse, in this case it requires that the individual operator know the normative requirements of the configuration they write (you are REQUIRED to provide an IPv4 address, and PERMITTED to also provide a domain name to clients that support that option). The only advantage of defining multiple options for the same configuration value is that such a heavy-handed set of normative requirements _can_ be defined to ensure that clients are clearly informed of what the minimum requirements are. an alternative would be to define one option with a sub-code field. This field indicates whether the option carries an IP address or a name option. Which is section 5 of the same draft[1], Conditional Formatting is Hard. DHCP software has to be designed to allow the operator and users to use new options that weren't defined at the time the software was released - or for example are defined by vendors. Conditional format bytes have not entered the mainstream of the mechanisms offered by today's software, if even one implementation supports such a mechanism it is unknown to me. So the use of conditional formatting places adoption of the option on the 5-year software development cycle, new code must be written to use the option in both client and server, so it cannot realistically be touched by mortals until then. Conditional formatting also removes the question of choice from the DHCP client software, which often prefers to implement the least that is required. Since you cannot enumerate the formats you support, and you cannot expect a DHCP server to translate formats, a client must support all formats (and all future formats!). This means for example a B4 client that might need a DNS recursive server configuration for no other purpose than to locate its AFTR endpoint address must carry along with it a recursive stub resolver specifically for that purpose. It is a non-starter, in my opinion. A third option that has been suggested, through the years, is to define an encapsulated option space - sub options. This is a DHCP level option that contains code-length-values, and so each different format for the configuration parameter is given a unique code. This has all the same problems as the Aliasing problem, except that it offers an opportunity to define a sub-option code that allows a client to advertise what options it supports (a sub-option-request-sub-option). I don't think there are any major criticisms of this approach except that it again requires new code in both client and server. [1] Hankins, D., Guidelines for Creating new DHCP Options, draft-ietf-dhc-option-guidelines-05, February 2009. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgpl3Q6Wa2jwH.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
On Tue, Oct 12, 2010 at 07:26:10AM -0700, Ted Lemon wrote: If you absolutely have to have the FQDN option, then get rid of the IP address option.That eliminates the interoperability problem. In any case, though, you need to issue a new draft. As a B4 implementor, I reject the onerus requirement imposed to contain a DNS recursive stub resolver in B4 equipment, and to complicate the configuration of the B4 software to be conditional on the success (through retries) of its resolution. I will simply not use the IETF standard option in this case, and continue to configure our B4 elements using a VSIO option. The address option must be defined. If a name option must also be defined, then we must define the strict normative requirements to permit software to navigate the confusion that having both impose. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgppEDCdIhlIQ.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Folks, VoIP protocols in MGCP and SIP have been supporting IP address and FQDN for a long time. In VoIP deployment with FQDN use, the deployment always keeps a local name resolver. So why not look carefully at the use cases operators are presenting to advocate use of both FQDN and IP address and then go from there. I appreciate the feedback on DHCPv6 design style to not use two entities to represent the same primitive but if DHCPv6 is such a stick in the mud, we could go with some other control mechanism. After all several protocols use FQDN and IP address interchangeably and the deployments are working fine. Hemant -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Thursday, October 07, 2010 4:07 AM To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt 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 : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ 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] DHCPv6 AFTR name option is needed
On Oct 12, 2010, at 4:58 PM, Hemant Singh (shemant) wrote: I appreciate the feedback on DHCPv6 design style to not use two entities to represent the same primitive but if DHCPv6 is such a stick in the mud, we could go with some other control mechanism. After all several protocols use FQDN and IP address interchangeably and the deployments are working fine. You've hit the nail on the head, Hemant. Custom protocols have no trouble with this. It's because DHCP is a general-purpose protocol that this becomes a problem. If you want a custom protocol, you should define a custom protocol. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
A general question. If 6rd could become an RFC in RFC 5969 with no mention of FQDN for the BR, what is so special about DS-Lite and deployments that a FQDN is needed by DS-Lite for the AFTR? I would think the same FQDN issue would arise in 6rd as well... What did I miss? Thanks, Hemant -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, October 12, 2010 1:42 AM To: Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org Cc: Ullio Mario; Chairs Dhc; magli...@core3.amsl.com; Softwire Chairs; Softwires Subject: Re: [Softwires] DHCPv6 AFTR name option is needed Dear Raplh, Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Hi Hemant, As I know, since 6rd BRs are stateless, so you can configure an anycast address for load balancing stuff. Thanks, washam 2010/10/13 Hemant Singh (shemant) shem...@cisco.com: A general question. If 6rd could become an RFC in RFC 5969 with no mention of FQDN for the BR, what is so special about DS-Lite and deployments that a FQDN is needed by DS-Lite for the AFTR? I would think the same FQDN issue would arise in 6rd as well... What did I miss? Thanks, Hemant -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, October 12, 2010 1:42 AM To: Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org Cc: Ullio Mario; Chairs Dhc; magli...@core3.amsl.com; Softwire Chairs; Softwires Subject: Re: [Softwires] DHCPv6 AFTR name option is needed Dear Raplh, Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. Cheers, Med ___ 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] DHCP option for DS-lite
Dear Alain, all, I strongly object to define only a single AFTR address option. As I mentioned in previous e-mails, the FQDN name option is needed for some scenarios such as load balancing. Having DHCP server acting as a load balancer is not an option for us. If the problem is only with the language as mentioned by D. Hankins, then the spec should be clear enough. I hope the wg will re-consider this position and defines the name aftr option. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 12 octobre 2010 21:01 À : Softwires list Cc : Ralph Droms Objet : [Softwires] DHCP option for DS-lite Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only the IP address option in place. The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should be dealt with differently. Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this. David, Alain - The authors made a significant change to draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on IESG review and input from the dhc WG. The -05 rev is getting de facto review now, but you'll need to determine WG consensus for the changes in the -05 rev. - Ralph If you have a strong opinion that the decision of the authors is the wrong one, please speak up now. This window for comments will end in 7 days, on 10/19. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
