Subject: [v6ops] new draft: draft-bao-v6ops-rfc6145bis

From: [email-masked]
Date: Sat, 4 Jul 2015 04:47:02 -0700

A new draft has been posted, at http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look at it and comment.

---

From: Xing Li <[email-masked]>
Date: Mon, 06 Jul 2015 18:51:34 +0800

> A new draft has been posted, at http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look at it and comment.

We have submitted this draft to look for v6ops' comments.

The changes compared with RFC6145 are:

(1)  From the erratum report
      http://www.rfc-editor.org/errata_search.php?rfc=6145

(2)  From 6man's document concerning "Deprecating the Generation of IPv6 
Atomic Fragments"
      
https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/
      Ntote that RFC6145 already has this mechanism, but it is just an 
option. The rfc6145bis makes this mechanism the default and the only one.

(3)  Refer to RFC6791 for "Stateless Source Address Mapping for ICMPv6 
Packets"
      https://datatracker.ietf.org/doc/rfc6791/

(4)  Include EAM address mapping algoritm which is the current work of 
v6ops, "Explicit Address Mappings for Stateless IP/ICMP Translation"
      https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/
      There are some discussions concerning this issue, since EAM is an 
address mapping algorithm (RFC6052's alternative), not a protocol 
mapping algorithm.  We  include EAM in RFC6145bis because it is just a 
static configuration and simple. If additional details, for example 
hairpinning, needs to be included, I think those details should be in 
another document.

We are looking for the comments.

xing

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Alberto Leiva <[email-masked]>
Date: Fri, 24 Jul 2015 14:55:02 -0500

Hi

>   Destination Address:  In the stateless mode, which is to say that if
>      the IPv4 destination address is within a range of configured IPv4
>      stateless translation prefix, the IPv6 destination address is the
>      IPv4-translatable address derived from the IPv4 destination
>      address per [RFC6052], Section 2.3.  A workflow example of
>      stateless translation is shown in Appendix A of this document.
>      Besides the default algorithm defined [RFC6052], other mechanisms
>      also exist, which are defined in Section 6 of this document (EAM)
>      and in [I-D.ietf-softwire-map-t].
>
>      In the stateful mode (which is to say that if the IPv4 destination
>      address is not within the range of any configured IPv4 stateless
>      translation prefix), the IPv6 destination address and
>      corresponding transport-layer destination port are derived from
>      the Binding Information Bases (BIBs) reflecting current session
>     state in the translator as described in [RFC6146].

I find this a little excessive. It also seems to mandate no other
address translation mechanisms should exist (is this true?).

I suggest something like this:

    Destination Address: The address translation algorithm is left open for
    other documents to define. At time of writing, implementations can
    choose (according to needs) among RFC6052, RFC6146, RFC 6219,
    RFC6791, EAM ([I-D.ietf-v6ops-siit-eam]) and/or MAP-T
([I-D.ietf-softwire-map-t]).

Repeat (Or make an new section and point there) for IPv4-to-IPv6
source address, and the IPv6-to-IPv4 source and destination addresses.

On Mon, Jul 6, 2015 at 5:51 AM, Xing Li <[email-masked]> wrote:
> [email-masked] 写道:
>
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look at
> it and comment.
>
>
>
> address mapping algorithm (RFC6052's alternative), not a protocol mapping
> algorithm.  We  include EAM in RFC6145bis because it is just a static
> configuration and simple. If additional details, for example hairpinning,
> needs to be included, I think those details should be in another document.
>

---

From: Tore Anderson <[email-masked]>
Date: Sat, 25 Jul 2015 13:00:29 +0200

* Alberto Leiva
 
> address translation mechanisms should exist (is this true?).

Hi Alberto, and thank you for your feedback!

Fernando, Fred, Xing and I met on Friday morning to discuss 6145bis.
This exact issue came up. Suffice it to say that new text that
approaches the problem in much the same way you suggested is already in
the works, so please wait for -01 and let us know if that addresses
your concern in a satisfactory manner.

Tore