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

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 <xing@cernet.edu.cn> wrote:
> fred@cisco.com 写道:
>
> 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>