Subject: [v6ops] draft-anderson-v6ops-v4v6-xlat-prefix

From: Lee Howard <[email-masked]>
Date: Wed, 05 Oct 2016 15:26:05 -0400

This draft generated a lot of discussion at our last meeting, in Berlin, but there has been very little discussion since it was updated a month ago. 

Do people feel that this version addresses their concerns? Is this a good idea?

If there's interest, this will be on the agenda for our next meeting, including whether we should adopt it as a working group item.

Lee

---

From: Pier Carlo Chiodi <[email-masked]>
Date: Wed, 05 Oct 2016 22:37:43 +0200

> Do people feel that this version addresses their concerns? Is this a good idea?

I do believe this draft could solve some practical issues a Network Service 
Provider may encounter while deploying translation mechanisms, such as 
network segmentation and isolation. Having one or more prefixes outside my 
own address space (for example in case of load balancing) allows me to 
avoid to deploy new security-related configurations on every piece of my 
network.

I believe a dedicated prefix such as the one that will be possibly adopted 
with this draft could bring cleaner addressing plans and configurations and 
make ops and scalability easier. Contrarily I fear that the lack of a 
similar prefix could bring to wrong behaviours where service providers use 
reserved address space instead of NSPs from their own assignments.

My 2 cents.

--
Pier Carlo Chiodi

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Oct 2016 19:42:39 -0500

I supported the original version of this, I support this version too.  The
reduction from /16 to /48 is probably a reasonable compromise. Not sure we
really need to shred a /16 for this purpose, but a /48 is easily justified.
 :)

Basically, I think it's ready for adoption and then probably quickly on to
last call.

On Wed, Oct 5, 2016 at 2:26 PM, Lee Howard <[email-masked]> wrote:

> This draft generated a lot of discussion at our last meeting, in Berlin,
> but there has been very little discussion since it was updated a month ago.
>
> If there's interest, this will be on the agenda for our next meeting,
> including whether we should adopt it as a working group item.
>
> Lee
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
===============================================
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: Federico Santandrea <[email-masked]>
Date: Thu, 06 Oct 2016 09:02:36 +0200

Hello,

I have a doubt about this sentence contained in the draft:

"64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are intended for very similar uses, it is prudent to allow them to be referred to using a single aggregate (64:ff9b::/47)."

This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either range. Readers might be misled into thinking that they might just route for 64:ff9b::/47 and be done with it, but this would mean they are willing to forward packets that will be dropped afterwards anyway, since the addresses above are in a range which would not be allocated and therefore should not be routed.

Additionally I can't see benefit in keeping the sentence in the draft (i.e.: I don't think it really adds to the explanation).

Am I missing something here? Does anyone agree with this?

--
Federico Santandrea

Il giorno 5 ott 2016, 21:26, alle ore 21:26, Lee Howard <[email-masked]> ha scritto:
>This draft generated a lot of discussion at our last meeting, in
>Berlin, but there has been very little discussion since it was updated
>a month ago. 
>
>------------------------------------------------------------------------
>

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Oct 2016 15:21:29 +0200

* Federico Santandrea <[email-masked]>

> "64:ff9b:1::/48 [...] 64:ff9b::/96 [...] As these two prefixes are
> intended for very similar uses, it is prudent to allow them to be
> referred to using a single aggregate (64:ff9b::/47)."
> 
> This aggregate includes IPv6 addresses between 64:ff9b::1:0:0 and
> 64:ff9b:0:ffff:ffff:ffff:: inclusive, which aren't part of either
> range. Readers might be misled into thinking that they might just
> route for 64:ff9b::/47 and be done with it, but this would mean they
> are willing to forward packets that will be dropped afterwards
> anyway, since the addresses above are in a range which would not be
> allocated and therefore should not be routed.
> 
> Additionally I can't see benefit in keeping the sentence in the draft
> (i.e.: I don't think it really adds to the explanation).

Hi Federico, and thanks for your input.

I can remove this sentence in the next version, or try to reformulate
it.

I do think there's still a valid reason to make sure the new prefix
and the RFC6052 WKP can be aggregated in a as small prefix as possible
(and if the new prefix is a /48 the smallest aggregate is obviously
going to be a /47).

This is for the simple reason that doing so will "taint" the least
possible amount of unallocated address space; the draft could have set
aside 64::/48 instead of 64:ff9b:1::/48, but in doing so both 64::/32
and 64:ff9b::/32 would be both end up "tainted".

(Of course, should the WG consensus be to prefer 64::/48 or cafe::/48 or
whatever instead, then it's fine by me and I'll be happy to update the
draft accordingly.)

Tore

---

From: Federico Santandrea <[email-masked]>
Date: Thu, 06 Oct 2016 16:03:55 +0200

I agree with that reasoning.

What about keeping that sentence, but changing the reservation request for Local-use IPv4/IPv6 Translation to actually be 64:ff9b::/47 (instead of 64:ff9b:1::/48)? This way it would be really true that the two can be aggregated, and the extra addresses that are not yet covered by neither RFC6052 or the draft could then be used in the future by similar translation techniques.

If instead we have the 64:ff9b:1::/48 and 64:ff9b::/96 reservations, in theory smaller subnets in the middle of the two can be used in some other way, and then aggregating the two blocks wouldn't be as clean.

--
Federico Santandrea

---

From: David Farmer <[email-masked]>
Date: Thu, 6 Oct 2016 09:15:28 -0500

> whatever instead, then it's fine by me and I'll be happy to update the

I'm fine with anything up to a /32 begin reserved for v4v6 xlate purposes
in the most general sense, overall this purpose easily justifies at least
the default allocation we make to an ISP.

My recommendation is it keep what I view as the intent of the current text
and simply reserve the whole /47, or larger, for generalized v4v6 xlate
purposes, but further reserving the space beyond 64:ff9b:1::/48 for future
designated purposes, such as additional WKPs, etc...  Allowing the use of
64:ff9b:1::/48 as currently specified in detail, but allowing use of the
aggregated /47 prefix, or larger, in a way similar to the current text.

Thanks

---

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Oct 2016 16:25:12 +0200

Hi again,

> What about keeping that sentence, but changing the reservation
> request for Local-use IPv4/IPv6 Translation to actually be
> 64:ff9b::/47 (instead of 64:ff9b:1::/48)?

I disagree. That the newly reserved prefix encompassed the RFC6052 WKP
was actually one of the things I didn't like about the previous version
of the draft.

RFC6052 reserves 64:ff9b::/96 and defines how it may and may not be
used.

This draft reserves a prefix that may be used in some circumstances
64:ff9b::/96 may not.

So by having this draft reserve a prefix that encompasses 64:ff9b::/96,
the draft must make an exception out of 64:ff9b::/96 (or it would need
to update RFC6052 so that the same rules apply for the entire /47).
Neither of the options is particularly appealing.

Thus I'd like to let the RFC6052 WKP stay as it is without having this
draft attempt to enroach on RFC6052's turf, so to speak.

> This way it would be really true that the two can be aggregated, and
> the extra addresses that are not yet covered by neither RFC6052 or
> the draft could then be used in the future by similar translation
> techniques.

Well, actually, it could not. If this draft grabbed all of
64:ff9b::/47, then any new translation technique that wants a dedicated
WKP similar to RFC6052 would need to grab a prefix from outside of
64:ff9b::/47 (or it would need to update this draft and change the
rules of how 64:ff9b::/47, or subsets of it, may and may not be used.)

By leaving the space between 64:ff9b::/96 and 64:ff9b:1::/48
unallocated, a new draft that wants an WKP has the possibility to ask
the IANA for a new prefix from that range (assuming it can fit, i.e.,
that the desired prefix is a /49 or smaller).

That said, the reservation made in this draft is on purpose made
generic enough so that an operator will be permitted to use
64:ff9b:1::/48 for any new translation technique that might show up in
the future (assuming that doesn't come in conflict with something about
the new technique itself of course).

Tore

---

From: Federico Santandrea <[email-masked]>
Date: Thu, 06 Oct 2016 18:15:50 +0200

> draft attempt to enroach on RFC6052's turf, so to speak.

You are right, having two separate blocks is better than having to make
modifications of that kind.

I am convinced on this one.

-- 
Federico

---

From: David Schinazi <[email-masked]>
Date: Thu, 06 Oct 2016 09:26:44 -0700

Hi,

I've read the updated draft (-02) and like it much more than the original.
I think the discussion that happened in this thread about why the
new prefix does not encompass the WKP is valuable and should
be added to the document.

I also have a question about the interaction between this and
RFC 6052. It is my understanding that the rationale for not allowing
the WKP to translate RFC1918 space was that the WKP is domain-specific.
The new prefix is also domain-specific, and has similar rules to the
WKP with regards to inter-domain routing. For this reason I think
this document should discuss if translating RFC1918 addresses
is allowed or not. If a NAT64 is configured with prefix 64:ff9b:1:fffe::/96,
is it allowed to translate 10.0.0.1?

Thanks,
David

> On Oct 6, 2016, at 09:15, Federico Santandrea <[email-masked]> wrote:
>

---

From: Tore Anderson <[email-masked]>
Date: Fri, 7 Oct 2016 07:18:57 +0200

* David Farmer <[email-masked]>

> I'm fine with anything up to a /32 begin reserved for v4v6 xlate
> purposes in the most general sense, overall this purpose easily
> justifies at least the default allocation we make to an ISP.

Noted. I suppose this I could simply poll the WG about this. Perfect
bike-shedding opportunity! Some possible options:

* 64::/32 - easiest for human eyes and memory

* 64::/48 - as above, but sized more stingily

* 64:ff9a::/32 - adjacent to RFC6052 WKP (would make
  64:ff9a:: -- 64:ff9b::ffff:ffff a continuous range of IPv4/IPv6
  translation addresses with no holes) and allows covering both
  prefixes (plus some unallocated space) by shortening the prefix by
  only 1 bit (64:ff9a::/31).

* 64:ff9a:ffff::/48 - more stingy option adjacent to WKP
  (64:ff9a:ffff:: -- 64:ff9b::ffff:ffff would be a continous range)

* 64:ff9b:1::/48 - more stingy option that is as adjacent to the
  RFC6052 WKP as possible while allowing for a covering aggregate by
  shortening prefix by only 1 bit (64:ff9b::/47). Also possibly slightly
  more recognisable than the others for human eyes due to it having the
  same 32 most significant bits as the WKP.

I don't really have a strong opinion - I'd just like to have *a* prefix
for this purpose, regardless of its actual value. But if I could choose
freely I'd probably take 64::/32 for the sake of my colleauges who'd
regularly encounter these addresses in logs and ACLs and so on.

How about you - any preference?

> My recommendation is it keep what I view as the intent of the current
> text and simply reserve the whole /47, or larger, for generalized
> v4v6 xlate purposes, but further reserving the space beyond
> 64:ff9b:1::/48 for future designated purposes, such as additional
> WKPs, etc...  Allowing the use of 64:ff9b:1::/48 as currently
> specified in detail, but allowing use of the aggregated /47 prefix,
> or larger, in a way similar to the current text.

Honestly I think this would complicate the draft needlessly. If I
understand you correctly it would make the draft do three distinct things:

1) Reserve 64:ff9b:1::/48 for local use translation (as the draft
   currently does and is what I'm really trying to accomplish).

2) Reserve the range 64:ff9b::1:0:0 -
   64:ff9b:ffff:ffff:ffff:ffff:ffff:ffff (or 64:ff9b::1:0:0/96,
   64:ff9b::2:0:0/95, ..., 64:ff9b:8000::/49 if you prefer) for future
   standards track action regarding IPv4/IPv6 translation.

3) Start out by saying something about 64:ff9b::/96 but then do a 180
   and clarify that it doesn't really say anything about 64:ff9b::/96
   after all.

I'd prefer for my drafts to avoid "feature bloat", and instead focus on
doing just one thing and do that well. (That would be #1.)

Second, is it really any point in reserving the range in #2
specifically? It is already marked «Reserved by IETF» (RFC4291 section
4) in the IANA registry. Point #2 would add that it's for IPv4/IPv6
translation, but is that really necessary? To me it seems extremely
unlikely that some other IETF draft (not related to IPv4/IPv6
translation) will ask for a reservation from this specific range anyway.

Tore

---

From: Tore Anderson <[email-masked]>
Date: Fri, 7 Oct 2016 07:30:26 +0200

Hi David,

* David Schinazi <[email-masked]>

> I've read the updated draft (-02) and like it much more than the
> original. I think the discussion that happened in this thread about
> why the new prefix does not encompass the WKP is valuable and should

Thanks, and noted.

> the WKP to translate RFC1918 space was that the WKP is
> domain-specific. The new prefix is also domain-specific, and has
> similar rules to the WKP with regards to inter-domain routing. For
> this reason I think this document should discuss if translating
> RFC1918 addresses is allowed or not. If a NAT64 is configured with
> prefix 64:ff9b:1:fffe::/96, is it allowed to translate 10.0.0.1?

There is actually no interaction between this prefix and the RFC6052
WKP at all, beyond the fact that overcoming certain limitations of the
RFC6052 WKP is a key motivation for this draft.

One of those limitations is the limited size (the WKP only allows for a
single translation system in a network), another is the inability to
use the WKP in combination with RFC1918 space.

Due to the ongoing IPv4 exhaustion and IPv6 deployment organisations
might well find themselves in a situation where they have both some
kind of RFC1918 IPv4-only services in their network, as well as some
IPv6-only clients that need to access to those services. That can't be
done using the RFC6052 WKP, while the prefix reserved by this draft
would facilitate such communication.

So to answer your question: yes, a NAT64 configured with
64:ff9b:1:fffe::/96 would indeed be allowed to translate 10.0.0.1. I
will make sure to point this out explicitly in the next revision.
Thanks again!

Tore

---

From: Ross Chandler <[email-masked]>
Date: Fri, 7 Oct 2016 10:52:13 +0100

> On 7 Oct 2016, at 06:18, Tore Anderson <[email-masked]> wrote:
> 
etc.
> currently does and is what I’m really trying to accomplish).

Maintaining the 64:ff9b base would make it more unambiguously identifiable as a translation prefix when glancing at prefix lists.
64:ff9b:1::/48 seems like the best choice.

Ross