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

[Tore Anderson <[e-mail]>]

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