Stateless Source Address Mapping for ICMPv6 Packets
draft-ietf-v6ops-ivi-icmp-address-07

No objection to the publication of this document, but a few points anyway

1.
OLD:

 [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm"
   document. states that "the IPv6 addresses in the ICMPv6 header may
   not be IPv4-translatable addresses and there will be no corresponding
   IPv4 addresses representing this IPv6 address.

NEW:
 [RFC6145] section 5.3 of the "IP/ICMP Translation Algorithm"
   document. states that "the IPv6 addresses in the ICMPv6 header may
   not be IPv4-translatable addresses and there will be no corresponding
   IPv4 addresses representing this IPv6 address.


2. "The recommended approach to source selection is to use the a single"

3. From the write-up:

   (1) What type of RFC is being requested (BCP, Proposed Standard, 
   Internet Standard, Informational, Experimental, or Historic)? Why is 
   this the proper type of RFC? Is this type of RFC indicated in the title 
   page header?

   This document is proposed as a Best Current Practice. The argument 
   for that status is as follows. The original authors, from CERNET, 
   observed an operational problem in their network, which uses a stateful 
   IPv4/IPv6 Translator between an IPv4-only domain (CERNET) and an 
   IPv6-only domain (CERNET2). 

I guess it's a typo: statefull -> stateless

4.  <RANT>
That's a typical IETF document that contains all the information required, but ONLY contains the minimum piece of information.
Sure if you have all the background (RFC 6145, RFC 6052, ICMP, stateless/statefull, IPv6 & IPv4), this draft is a piece of cake. However, I wonder: are we doing a good service to new comers by reducing the content to the minimum?
No, we're simply adding to the argument that RFCs are a pain to read.
An extra diagram with an example, in the introduction, with the following pieces of information, would have been so much easier: 
	- IPv6 domain, 
	- IPv4 domain, 
	- request goes in one direction (indicate the IP address, before and after the translation), 
	- ICMPv6 comes in the other direction (indicate the IP address before the translation), 
	- src IP address as ???  
	- etc...
And also explaining why it's not an issue with statefull (or simply a reference to http://tools.ietf.org/html/rfc6145#section-1.3) would be useful information
</RANT>

Regards, Benoit

I have cleared my DISCUSS based on Ron's promise to add clarifying text on what constitutes a translatable address.

A nit:

Section 5., paragraph 1:

>    If a pool of public IPv4 addresses is configured on the translator,
>    it is RECOMMENDED to randomly select the IPv4 source address from the
>    pool.  Random selection reduces the probability that two ICMP
>    messages elicited by the same TRACEROUTE might specify the same
>    source address and, therefore, erroneously present the appearance of
>    a routing loop.  An enhanced traceroute application is RECOMMENDED in
>    order to obtain the IPv6 source addresses which generated the ICMPv6
>    messages.

  What is the RECOMMENDED about the application? Does it say that one
  should use such enhanced application? If yes, I do not see that
  the RECOMMENDED is the right term here, as it is nothing about
  the protocol, but more a recommendation for the user of such a
  traceroute application.

I understand that the third paragraph of section 3.1 states that the
address translation should provide additional information about the
source address, and suggests that a pool of IPv4 addresses could be
used to provide that additional information.  Yet, the mechanism
described in section 5 randomly chooses an IPv4 address from a pool of
IPv4 addresses.  I don't see how the random selection of the IPv4
address provides any information.  I recognize that the IPv6 source
address is carried in the ICMP extension.

If the IPv4 address is chosen at random from a pool of addresses, what
is the advantage over just using, as suggested in section 4, a single
IPv4 address as the source address in all translated ICMP messages?

In the interests of matching what I would think of as the meaning of
the title and the actual mechanism, I would call this mechanism a
"random selection mechanism".  There is no mapping, as I would
understand the word, involved.

If, on the other hand, the pool were composed of IPv4 addresses that
in some way convey topology information to the receiver, and the
IPv4 source address were chosen based on the non-translatable IPv6
address, I would consider this mechanism to be a "mapping".

I support Brian's Discuss about "What constitutes a non-translatable
address?"

I've cleared under the understanding that this will move to PS

1) s1: r/document. states/document states

2) s2: The nits checker is complaining.  I believe it's because the keywords aren't in quotes.

3) s3.1: slight rewording:

OLD:

 The source address used, should not cause the ICMP packet to be a
 candidate for discarding.

NEW:

 The source address used, should not cause the ICMP packet to be
 discarded.

4) s3.1: I find the the 2nd sentence in s3.1 odd - is 6145 only applicable to private internets?  Isn't not using 1918-addresses really about not using these addresses on the internet as per RF 5735?  Maybe:

OLD:

 The possibility of uRPF filters in the
 path are a critical consideration [RFC3704] which precludes the use
 of private IPv4 address space [RFC1918] in this context.

NEW:

  Private IPv4 address space [RFC1918] SHOULD NOT be used as the
  source addresses because they should not appear on the internet
  [RFC5735].

5) s3.1: I think this is missing a verb

OLD:

 Another consideration for source selection is that it be possible for
 the IPv4 recipients of the ICMP message to be able to distinguish ...

NEW:

 Another consideration for source selection is that it should be possible
 for the IPv4 recipients of the ICMP message to be able to distinguish ...

6) s3.2: Once more with feeling ;) it's a BCP after all

OLD:

 The recommended approach to source …

NEW:

 The RECOMMENDED approach to source …

7) s4: Is the last sentence in s4 needed?  If you're going to do the extension just do it.

8) s5: Need some motherhood an apple pie about picking a random number.  Add a pointer to RFC 4086.

It seems like "Updates: 6145" might be considered, and I support Robert's question regarding BCP vs PS in that respect.