Subject: [v6ops] New Version Notification for draft-anderson-v6ops-v4v6-xlat-prefix-01.txt

From: Tore Anderson <[email-masked]>
Date: Tue, 21 Jun 2016 08:46:11 +0200

Hello WG,

I have just posted a new version of I-D.anderson-v6ops-v4v6-xlat-prefix.

The only change since -00 is to introduce the following paragraph in
section 5, based on a suggestion by Holger Metschulat (thank you!) that
was seconded by Alejandro Acosta:

  By default, IPv6 nodes and applications must not treat IPv6 addresses	
  within 64::/16 and outside 64:ff9b::/96 different from other globally	
  scoped IPv6 addresses.  In particular, they must not make any	
  assumptions regarding the syntax or properties of those addresses	
  (e.g., the existence and location of embedded IPv4 addresses), or the	
  type of associated translation mechanism (e.g., whether it is	
  stateful or stateless).

Details and links from the IETF Secretariat's announcement:

Name:		draft-anderson-v6ops-v4v6-xlat-prefix
Revision:	01
Title:		64::/16: An IPv4/IPv6 translation prefix
Document date:	2016-06-21
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-anderson-v6ops-v4v6-xlat-prefix-01.txt
Status:         https://datatracker.ietf.org/doc/draft-anderson-v6ops-v4v6-xlat-prefix/
Htmlized:       https://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-v4v6-xlat-prefix-01

Abstract:
   This document reserves the IPv6 prefix 64::/16 for use with IPv4/IPv6
   translation mechanisms.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 21 Jun 2016 18:46:46 +0000

Take a look at the attachment; it identifies a number of RFCs and three internet drafts (including yours) that comment on 64:ff9b::/96. I suspect that your draft updates all, or at least several, of those RFCs, and that it might be worthwhile corresponding with the authors of the other two drafts.

I thought about section 3.3 of RFC 6724, which says in effect that any source address that does not imply a translator should be preferred over a source address that does. However, that is *as*a*source*address*, and the host would be using 64:ff9b::/32 as a destination address (responding to a session that came in, and it has no reason to think about whether it was through a translator). So I guess it doesn't update that.

> On Jun 20, 2016, at 11:46 PM, Tore Anderson <[email-masked]> wrote:
> 
> Hello WG,
>

---

From: Tore Anderson <[email-masked]>
Date: Wed, 22 Jun 2016 07:43:21 +0200

Hi Fred, and thanks for your feedback!

> Take a look at the attachment; it identifies a number of RFCs and
> three internet drafts (including yours) that comment on 64:ff9b::/96.
> I suspect that your draft updates all, or at least several, of those
> RFCs, and that it might be worthwhile corresponding with the authors
> of the other two drafts.

The draft states that «64:ff9b::/96 may only be used according to
[RFC6052]».

My reasoning for this is that any code or standard that assumes
64:ff9b::/96 has the precise properties and restrictions described in
RFC6052 should be able to continue to do so without modifications.
Anyone happily using 64:ff9b::/96 today can safely ignore this draft,
for them nothing changes.

The gist of what the draft does, on the other hand, is to legitimise
the use of all the *other* prefixes in 64::/16 for generic IPv4/IPv6
translation mechanisms.

That is, allow operators to configure their NAT64 or IVI or SIIT-DC or
$whatever translation boxes with prefixes such as 64::/96, 64:46::/32
or whatever.

IFF the technology is using RFC6052 mapping, then such usage
essentially amounts to the prefix being used as a RFC6052
«Network-Specific Prefix». However I'd also like for it to cater to
technologies that do not use RFC6052 mapping (such as RFC6219 section
3.1-style IVI or whatever new stuff someone invents in the future).

> I thought about section 3.3 of RFC 6724, which says in effect that
> any source address that does not imply a translator should be
> preferred over a source address that does. However, that is
> *as*a*source*address*, and the host would be using 64:ff9b::/32 as a
> destination address (responding to a session that came in, and it has
> no reason to think about whether it was through a translator). So I
> guess it doesn't update that.

Ack. Also note that the -01 version of the document does not demand
that the 64::/16 addresses embed IPv4 addresses (except for
64:ff9b::/96 as described above), which is what section 3.3 of RFC 6724
talks about.

So in summary I think the only document my draft do need to update from
the list you sent is RFC6890. 64::/16 would clearly be special-purpose.

Tore

---

From: David Farmer <[email-masked]>
Date: Wed, 22 Jun 2016 02:00:59 -0500

I like this idea, however, before we completely shred all of 64::/16
maybe we should consider reserving part of it for future standards
actions.  Would we ever want to designate another WKP different than
64:ff9b::/96?  Maybe reserve 64:ff00::/24 from 64::/16 requiring
standards action for use.  Just a thought. ;)

Also, the IANA considerations sections should designate the boolean
values to go in the IANA IPv6 Special-Purpose Address Registry, just
so there isn't any disagreements.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Tore Anderson <[email-masked]>
Date: Wed, 22 Jun 2016 09:21:22 +0200

Hi David,

* David Farmer <[email-masked]>

> standards action for use.  Just a thought. ;)

That makes sense to me, and fits well with the already specified WKP
from RFC 6052 falling within that range. I'll include that in -02
unless anyone objects.

> so there isn't any disagreements.

Noted. Will include that in -02.

Thanks for your input!

Tore