The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
draft-xli-behave-ivi-07

[Ballot comment]
The Gen-ART Review by Elwyn Davies on 4 January 2010 provided many
  suggestions for greater clarity and many other editorial improvements.
  Please conside these suggestions.

  Elwyn also said:
  >
  > It also needs a fair bit of attention from somebody whose mother
  > tongue is English.  I have sent a file to the authors with lots of
  > suggestions for this work.

[Ballot comment]
I have a minor question about translating unmapped IPv6 addresses.  In section 3.6:

  [...] the inverse
  mapping for unmapped addresses is defined in this document.  In the
  current prototype, a pseudo IPv4 address is generated.

I can't find the the description of the inverse mapping or how the prototype generates the IPv4 address.  Nit: I assume the generated IPv4 address is a real IPv4 address, so "pseudo IPv4 address" isn't quite accurate.

In Appendix B:

  Note that the non-IVI IPv6 addresses are mapped to 202.38.17.186,
  which is defined in this document (the first two sections are the
  IPv4 prefix of /16 of the IVI translator interface and the last two
  sections are the autonomous system number 4538).

I don't see any other occurrences of "202.38.17.186" in the document, so I'm not sure what the text is referring to.  I also can't find the definition of the translation (for clarity, I would call this a "translation" because the IPv6 address is "unmappable"), which I'm guessing is referred to in the parenthetical text.

[Ballot comment]
I have a minor question about translating unmapped IPv6 addresses.  IN section 3.6:

  [...] the inverse
  mapping for unmapped addresses is defined in this document.  In the
  current prototype, a pseudo IPv4 address is generated.

I can't find the the description of the inverse mapping or how the prototype generates the IPv4 address.  Nit: I assume the generated IPv4 address is a real IPv4 address, so "pseudo IPv4 address" isn't quite accurate.

In Appendix B:

  Note that the non-IVI IPv6 addresses are mapped to 202.38.17.186,
  which is defined in this document (the first two sections are the
  IPv4 prefix of /16 of the IVI translator interface and the last two
  sections are the autonomous system number 4538).

I don't see any other occurrences of "202.38.17.186" in the document, so I'm not sure what the text is referring to.  I also can't find the definition of the translation (for clarity, I would call this a "translation" because the IPv6 address is "unmappable"), which I'm guessing is referred to in the parenthetical text.

[Ballot comment]
I support the publication of this document.
While it was clearly an experiment and would have been suitable for publication as Experimental when it was first written, I agree with Jari that as time has moved on, thi should be published as Informational to describe the experiment that has been completed with lessons learned.

I have re-reviewed the draft. We are almost there, but I had a few smaller issues left:

> 2. Lost of the end-to-end address transparency. If algorithm based 
>            mapping is defined, the end-to-end address transparency can be 
>            maintained.

I'm not sure the argument holds water, at least not completely. There are many aspects of address transparency. Having addresses change underneath at all causes some of the fundamental trouble, dynamics, unexpected changes, and compressed (not 1-1) mappings cause the rest. Your algorithm based model restores some of these aspects, but not all. Please consider a small rewrite above.

> o DNSSEC will break if a separate IVI DNS is used for the A record to AAAA record translation.

DNS what is used? Presumably you meant that DNSSEC prevents automatic translation of records, if the translation of records and the DNSSEC verifier are in different devices. However, just as with DNS64, I think it would be fine to have a translation in a local DNS server that also verifies DNSSEC. Or in the host, if the host both translates the DNS entry and again verifies DNSSEC validity.

>  6. The issues related to support refferals. The stateless 
>            translation and the DNS decoupling can make the refferal handling 
>            simplier.

A too overly positive formulation, IMO. DNS (and to some extent DNS decoupling helps), but it really does not remove the issues related to handing out referrals to IP addresses that the other side may not understand or which may have only local significance. Please reformulate.

> 4. Loss of information due to incompatible semantics between IPv4 
>            and IPv6 versions of headers and protocols. This kind of effects 
>            can be minimized via carefully handling of the protocol 
>            translation.

Maybe: "A partial remedy to this is the proper attention to the details of the protocol translation. However, some semantic differences remain."

Overall, I think Section 1.1 should still be improved a bit. The above suggestions are part of it, but I also wonder if you should simply add a paragraph that explains what the remaining issues in IVI are; surely its not perfect?

Editorial:

> 2. Lost of the end-to-end address transparency.

Loss of ...

> the firewall filter rule 
>            should count this constrain. 
>           
... there may a practical constraint for the construction of such rules.

> This problem can be solved either via 
>            ALG or translate the address back to its original form. 
>       

an ALG or through translation of the address back to its original form. (But I'm not sure who is translating what here. Is there a second translation somewhere?)

My plan is that this draft be published as an RFC as an AD sponsored individual submission. After discussion with my fellow ADs and relevant working group chairs, a fair model for doing this appears to be documenting what you have done, but adding a normative reference to the standards track scheme being developed in BEHAVE. This allows your RFC to enter the RFC Editor's queue as soon as its ready, but it will be published at the same time as the BEHAVE results (which I think will happen relatively soon). Your document needs to be free of technical problems, clear, fully specified, and honest about its limitations.

I have now read the document -- apologies for taking so long time. This was mostly due to the queue that built up while I was sick.

Overall, the document well written and easy to understand. Good work! However, there were also a number of areas that were underspecified or missing. I would like you to revise the document to address these. In some cases you may be able to delete text, in other cases you need to write some additional specification text.

Please see detailed comments below:

Technical:

> The IPv4
>    address depletion problem makes the dual-stack approach inapplicable
>    [COUNT ].

This isn't really right. First of all, your reference is to the count-down, not to the conclusion that you state above. Secondly, I don't believe the conclusion is correct. To quote draft-arkko-townsley-coexistence:

Dual-Stack continues to be the most
  well understood and recommended deployment model.  Note that Dual-
  Stack is not limited to situations where all hosts can acquire public
  IPv4 addresses.  A common deployment scenario is running Dual-Stack
  on the IPv6 side with public addresses and on the IPv4 side with just
  one public address and a traditional IPv4 NAT.  Generally speaking,
  offering native connectivity with both IP versions is preferred over
  the use of translation or tunneling mechanisms when sufficient
  address space is available.

Here's a possible rewrite of the paragraph from your document:

  The experiences for the IPv6 deployment in the past 10 years strongly
  indicate that for a successful transition, the communication between
  IPv4 and IPv6 address families should be supported [JJI07].  However,
  the current transition methods do not fully support this requirement
  [RFC4213].  For example, dual-stack hosts can communicate with both
  the IPv4 and IPv6 hosts, but the single-stack hosts can only
  communicate with the hosts in the same address family.  The IPv4
  address depletion problem makes the dual-stack approach inapplicable
  [COUNT].  The tunneled architectures can link the IPv6 islands cross
  IPv4 networks, but they cannot help the communication between two
  address families [RFC3056] [RFC5214] [RFC4380].  The translation
  architectures can relay the communications for the hosts located in
  IPv4 and IPv6 networks, but the current implementation of this kind
  of architecture is not scalable and it cannot maintain the end-to-end
  address transparency [RFC2766] [RFC3142] [RFC4966] [RFC2775].

=>

  The experiences for the IPv6 deployment in the past 10 years
  indicate that the ability to communicate between
  IPv4 and IPv6 address families would be beneficial. However,
  the current transition methods do not fully support this requirement
  [RFC4213].  For example, dual-stack hosts can communicate with both
  the IPv4 and IPv6 hosts, but the single-stack hosts can only
  communicate with the hosts in the same address family.  While dual-stack
  approach continues to work in many cases even in the face of IPv4 address
  depletion [COUNT], there are situations where it would be desirable to
  communicate with a device in another address family.
  Tunneling-based architectures can link the IPv6 islands cross
  IPv4 networks, but they cannot help the communication between two
  address families [RFC3056] [RFC5214] [RFC4380].  Translation
  can relay the communications for the hosts located in
  IPv4 and IPv6 networks, but the current implementation of this kind
  of architecture is not scalable and it cannot maintain the end-to-end
  address transparency [RFC2766] [RFC3142] [RFC4966] [RFC2775].

>                Figure 1: An IPv6 network to IPv4 Internet

Isn't there more than the-v4-internet to an-ipv6-network in IVI? Surely it allows at least the-ipv6-internet to an-ipv4-network mode as well?

> bit 32 to bit 39 are all one's as the identifier
>    of IVI,

Why?

>                            Figure 5: IVI Routing

Please use the official example IPv4 addresses and not RFC 1918 addresses, unless you really meant to use 1918 space... see draft-iana-ipv4-examples.

> 4.2. DNS Service for the IVIG6(i) Addresses
>
>    For resolving the IPv6 form of the global IPv4 space (IVIG6(i)), each
>    ISP must provide customized IVI DNS service for the IVI6(i) hosts.
>    The IVI DNS server is in dual stack environment.  When the IVI6(i)
>    host queries an AAAA record for an IPv4 only domain name, the IVI DNS
>    will query the AAAA record first.  If the AAAA record does not exist,
>    the IVI DNS will query the A record and map it to IVIG6(i) and return
>    an AAAA record to the IVI6(i) host.

This needs a more complete specification. So, you aren't returning the A record at all if there's an AAAA record? And vice versa? How does this interact with DNSSEC? Algorithms used by hosts to decide which IP version to use?

> 5.2. Double IVI
>
>    The IVI mechanism can support the double IVI service, i.e. a stub
>    IPv4 network can be connected to an IVI translator to reach the IVI6
>    network and via another IVI translator to reach the IPv4 Internet
>    [RFC4925]
>
>    A more interesting scenario is to integrate the functions of the
>    first IVI translator into the end system.  In this case, the
>    application software is IPv4 based and there is no need to have ALG
>    support in the IVI translator when it is communicating with IPv4
>    hosts.



Are these things something that you have actually implemented, and are key to IVI? I would be very careful in just including the core parts in the specification, and these didn't feel like that.

> 5.3. Using RFC1918 Address Blocks
>
>    The private IPv4 address blocks [RFC1918] can be used as the IVI4.
>    In this case, an IPv4 NAPT can be used to convert the public IPv4
>    addresses to private IPv4 addresses and an IVI translator then
>    translate the IPv4 packets to IPv6 packets.  Note that the resulting
>    IPv6 addresses are not private addresses since they are embedded into
>    globally routable IPv6 prefixes and this recovers the end-to-end
>    connectivity in the IPv6 Internet for the networks using private IPv4
>    addresses.
There should be something here about what this gives to the organization. It certainly does not provide ipv4-internet-to-an-ipv6-network...

>    The IVI6(i) can be temporally multiplexed inside the ISP(i)'s /32.
>    This is to say that the ISP can dynamically assign IVI6(i) to an end
>    system when it requests the IPv4 communication service and release
>    the IVI6(i) when the communication is finished.
> 

This is underspecified. How do you know when the communication starts and finishes?

> 5.5. IPv4 Address Transport-layer Port Multiplexing
>
>    To further increase the utilization ratio of the public IPv4
>    addresses, the port multiplexing can be used [RFC2766] [RFC4966].
>    This is to say that a single IPv4 address IVI4(i) can be used for
>    multiple IVI6(i) addresses under the condition that these individual
>    IVI6(i)s host can only use a subset of the 65,536 port numbers.  For
>    example, if the port multiplexing ratio is 128, each IVI6(i) can only
>    use 512` concurrent port numbers to communicate with IPv4 Internet.
>    The mapping mechanism is to use the SUFFIX in the IVI address mapping
>    mechanism to define the coding method to the perform unique mapping
>    between IVI4(i) and IVI6(i).  The specification of the SUFFIX coding
>    method and the corresponding operation scheme will be presented in
>    another document.

This too is underspecified. I wonder if the document needs to include the multiplexing part at all. How about stating just that multiplexing is possible both in time and port numbers, but is not specified in this document?

> The IVI6 address has special format (for example IVI4=202.38.114.1/32
> and IVI6=2001:250:ffca:2672:0100::0/72), therefore, the stateless
> IPv6 address auto-configuration cannot be used.  However, the IVI6
> can be assigned to the IPv6 end system via manual configuration or
> stateful auto-configuration via DHCPv6

Underspecification. You need to talk about how to set the networks so that these addresses can be used. For instance, presumably this means multiple networks within the site have the same /64 prefix. Do you recommend setting on-link bit to zero in RAs for this prefix? How does routing work? Is there a difference between situations where one IPv4 /24 is in one subnet vs. where it needs to be in several?

>    Since each IPv6 host may have multiple addresses, it is important for
>    the host to use an IVI6(i) address to reach the global IPv4 networks.
>    The short-term work around is to use IVI6(i) as the default IPv6
>    address of the host.  The long-term solution requires that the
>    application should be able to select the source addresses for
>    different services.
> 
How is the default address set in terms of existing mechanisms (RFC 3484)? Do they allow this? Or do you need to limit the prefixes you configure for your networks to achieve this (e.g., just configure the IVI prefix)?

Missing things:

The document needs a section that talks about what its issues are. Perhaps you could start from the NAT-PT deprecation document which lists a number of issues with NAT-PT. Many of those are not present in IVI, but some are. For instance, what happens to referrals?

Security considerations need expansion to deal with the effects this has on security. I can see at least three effects: (a) IPsec and its NAT traversal, (b) DNSSEC, and (c) firewall filter rules.

What's the deal with the draft-baker-behave-ivi draft? Is draft-xli replacing that, its no longer relevant, or what?

Editorial:

> The IV stands for 4 and VI stands for 6, so IVI stands for the IPv4/IPv6 translation.
> 

In roman numerals, IV stands for ...

> This document is a comprehensive report on
> the CERNET IVI design and its deployment in large scale public
> networks.
> 

Perhaps you could already here say: .... IVI design. IVI is an early design deployed in CERNET. The IETF standard IPv4 - IPv6 translation mechanism is defined in [BEHAVE-DOC].

> This document presents the CERNET IVI translation design and
> deployment for the IPv4/IPv6 coexistence and transition.  The IV
> stands for 4 and VI stands for 6, so IVI stands for the IPv4/IPv6
> translation.
> 

I think you need to expand CERNET in the first paragraph.

>    The experiences for the IPv6 deployment in the past 10 years strongly
>    indicate that for a successful transition,
I'd prefer to say ... indicate ... as opposed to ... strongly indicate ... (style issue, its better to say things like they are instead of trying to make them appear stronger by using extra words).

> It is
>    clear that IVI fits in the "an IPv6 network connected to the IPv4
>    Internet" scenario in the IETF behave Working Group definition
>    [BEHAVE ].
> 

A couple of years down the road no one will know what you are talking about. Expand what you mean here.

>    The requirements of the IVI mechanisms are:
mechanism? singular.

>    1.  It should be stateless for the scalability.

Maybe its just me, but the other requirements seemed more important. Consider moving this to the end.

> the addresses in this set will be
>      mapped to IPv6 via IVI mapping mechanism and physically used by
>      IPv6 hosts of ISP(i).
> 

s/physically//

> The SUFFUX are all

SUFFIX

>        route 0.0.0.0/0 with next hop equals to 192.168.1.2 .

extra space at the end, before "."

>    Due to the features of 1-to-1 address mapping and stateless, IVI can
>    support most of the existing applications, such as HTTP, SSH, Telnet
>    and Microsoft Remote Desktop Protocol.

The last one does feels a little bit out of place in this list. At least a reference is needed.

>  However, some applications
>    are designed such that IP addresses are used to identify application-
>    layer entities (e.g.  FTP).  In these cases, application layer
>    gateway (ALG) is unavoidable, but it can be integrated into the IVI
>    translator.
> 
Is there a reference that explains what to do in these ALGs? Some BEHAVE document, perhaps?

>    use 512` concurrent port numbers to communicate with IPv4 Internet.

Extra character

> The IVI translation algorithm presented in this document is
>    implemented in the Linux OS

There's a difference between something being in the OS (a part of the official tree, for instance) and something implemented for the OS. I think you mean the latter. Please use more exact wording. E.g., An implementation of IVI exists for the Linux operating system. The sources can be downloaded from [REF].

>    Note that the non-IVI IPv6 addresses are mapped to 202.38.17.186,
>    which is defined in this document (the first two sections are the
>    IPv4 prefix of /16 of the IVI translator interface and the last two
>    sections are the autonomous system number 4538).
> 

I don't understand what "defined in this document" means in this context. First I took it to mean that you have actually defined some address range that can be used as traceroute responses. But I suppose that is not the case, nor should be it yet -- we have the other document for that. Is 202.38/16 an address that CERNET holds? Could you consider using example IPv4 addresses here?

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Fred Baker (fred@cisco.com). He personally reviewed this version of the document and he believe this version is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Yes. He thinks the current version is ready for publication.

(1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

This document presents a working example of the v4/v6 Stateless translation in an operational network, which provides useful information for the interested community.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

This document splits its references into normative and informative and satisfies all the requirements.

(1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document presents the CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network connected to the IPv4 Internet" scenario. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in ISP's IPv6 addresses and these IPv6 addresses can therefore communicate with the global IPv6 networks directly and can communicate with the global IPv4 networks via stateless translators, which can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. This document is a comprehensive report on the CERNET IVI design and its deployment in large scale public networks.

Working Group Summary

Was there anything in the discussion in the interested community that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Was the document considered in any WG, and if so, why was it not adopted as a work item there?

This document can serve as a useful reference for the behave working group standard track documents, which presents the design and operational experiments in a large-scale operational network.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Yes, the Linux open source is available and can be downloaded from http://www.ivi2.org/IVI/. There are several vendors indicate their plan to implement the specification.