Hi Teemu thanks for the comments see comments below... teemu.savolainen@nokia.com escribió: I undrsatnd that the changes you are proposing are:
Thus for chapter 2.2/4.1. I propose additions of: - Translation architectures SHOULD be scalable for large numbers of hosts and high data speeds
that certainly makes sense to me,would you include it in the basic requirements (MUST) or in the SHOULD? (i mean you phrase it as a should but you propose to include it 4.1)
- Availability of translation mechanism service SHOULD be quickly discoverable
I also agree with this one, probably in section 4.2?
- Legacy IPv4-only applications on IPv6-nodes MUST continue working
I am not sure this has to do with the translation mechanisms that we are considering at this point... I mean, what we are considering here AFAIU, is a new box that you include in between the v4 world and the v6 world, so that they can communicate. There may require some modifications to the v6 host. For that it seems to me that this is somehow different transition tool, that fits in a different scenario?
So, i don't see this clear...
I say SHOULD instead of MUST, as there surely are deployment scenarios where scalability is not an issue or where discovery process can be slow.For chapter 3.5 I'd like to add Symbian as one well-known and widely used OS. There are also great volumes of vendor proprietary OS'es.
makes sense to me
could you provide text of where and what you propose to include as you did in the previous items?It should be acknowledged (if its not) that quite likely not a single transition solution will be suitable for everybody: - operator/organization with relatively large IPv4 address pool might prefer IPv4-over-IPv6 tunneling (static or dynamic) - i.e. long term lease of full IPv4 address to clients - operator/organization with relatively small IPv4 address pool might prefer translation or DSTM/APBP kinds of approaches - i.e. short term lease of IPv4 address(&port) to clients - operator/organization who deploys DSMIP or VPNs might want to use those as transition mechanism - operator/organization with large subscriber base (100s of millions ) might need more scalable solutions than operator with small subscriber base (e.g. smaller than RFC1918 address space) - ....
Thanks, marcelo
Best regards, Teemu-----Original Message-----From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of ext marcelo bagnulo braunSent: 15 May, 2008 00:49 To: v6ops@ops.ietf.org Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt Hi, we have submitted the new version of the requirements for translatorsAFAICT one issue that needs to be decided is whether we need solutions both for v4 initiated solution and v6 initiated solution or it is enough to hav solutions for v6 initiated solutions, especially without requiring modifications to the v4 nodes.During some of the discussion, for instance during the one on DNSSec, people have expressed that they don't feel that we need to require DNSSec support for v4 initiated communications cause these where not relevant.So, i guess we need to define this comments? Regards, marcelo Internet-Drafts@ietf.org escribió:A New Internet-Draft is available from the on-lineInternet-Drafts directories.This draft is a work item of the IPv6 Operations WorkingGroup of the IETF.Title : IPv4/IPv6 Coexistence and Transition:Requirements for solutionsAuthor(s) : M. Bagnulo, et al. Filename : draft-ietf-v6ops-nat64-pb-statement-req-00.txt Pages : 17 Date : 2008-05-13This note presents the problem statement, analysis and requirements for solutions to IPv4/IPv6 coexistence and eventual transition in a scenario in which dual stack operation is not the norm.A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statement-req-00.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.