Re: [nat66] Terminology: Definition for "IPv6 Realm"?

Fred Baker <fred@cisco.com> Thu, 29 April 2010 06:02 UTC

Return-Path: <fred@cisco.com>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8193A6949 for <nat66@core3.amsl.com>; Wed, 28 Apr 2010 23:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.413
X-Spam-Level:
X-Spam-Status: No, score=-105.413 tagged_above=-999 required=5 tests=[AWL=5.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA4K3QfRVVMg for <nat66@core3.amsl.com>; Wed, 28 Apr 2010 23:02:12 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5A4A03A6ADD for <nat66@ietf.org>; Wed, 28 Apr 2010 23:02:11 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkBAPm92EuQ/uCWiWdsb2JhbACdChUBAQEKCxERBhyiOpoMhRAE
X-IronPort-AV: E=Sophos;i="4.52,294,1270425600"; d="scan'208";a="60310043"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2010 06:01:57 +0000
Received: from [192.168.1.64] (dhcp-10-55-88-21.cisco.com [10.55.88.21]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3T61u1V004554; Thu, 29 Apr 2010 06:01:57 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="iso-8859-1"
From: Fred Baker <fred@cisco.com>
In-Reply-To: <F4562D4585113D42AC08DC47FDEC49B0027D60F9@FRVELSMBS23.ad2.ad.alcatel.com>
Date: Thu, 29 Apr 2010 08:01:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6390719D-467A-4F89-8040-50E8BF27A1CC@cisco.com>
References: <F4562D4585113D42AC08DC47FDEC49B0027D60F9@FRVELSMBS23.ad2.ad.alcatel.com>
To: Schwarz Albrecht <Albrecht.Schwarz@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1078)
Cc: nat66@ietf.org
Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2010 06:02:13 -0000

First let me verify assumptions on naming. When I talk about nat66, I am talking about the proposal in http://tools.ietf.org/html/draft-mrw-behave-nat66. If you're not, please proceed carefully. If you are proposing to replicate IPv4/IPv4 NAT in IPv6/IPv6 NAT without thought or change, you are probably correct. That's not the topic of this list, though.

If you are talking about network prefix translation, as proposed, reachability is not in question. The question is mutual use of prefixes. In a NAT66 world, an address as seen here as one prefix is reachable there as another prefix. Your definition depends on the IPv4/IPv4 concept that a NAT divides worlds into mutually unreachable domains. In NAT66 as defined in the nat66 spec, we have not made the world mutually unreachable. We have simply changed the prefix to make routing more scalable while we connect them.

Conceptual example.

In your domain, you are using, let's say, a ULA, and that is the only prefix by which you are known. I would want to call this your "realm". From your ISP, you are also provided with a prefix, and when the datagram from your computer crosses that domain boundary, the DMZ replaces the prefix and does whatever it is going to do about TCP/UDP checksums. In your domain, you are effectively provider-independent, able to work with multiple ISPs without renumbering equipment, and equally reachable through all of them. In ISP2's domain, you are in effect using a provider-allocated address, and routing scales as it does with any provider-allocated address.

Ditto with me, my domain, and my relationship with me set of ISPs including ISP1.

        ------         ------         ------         ------
      // My   \\     //      \\     //      \\     // Your \\
     /ULA Realm \   /    ISP1  \   /   ISP2   \   /ULA Realm \
    ||          || ||          || ||          || ||          ||
    | +---+     +---+           | |           +---+      +---+|
    | |Me |     |DMZ|         -------         |DMZ|      |You||
    | +---+     +---+           | |           +---+      +---+|
    ||          || ||          || ||          || ||          ||
     \          /   \          /   \          /   \          /
      \\      //     \\      //     \\      //     \\      //
        ------         ------         ------         ------

    |<- my realm ->|<--------  Core Realm ----->|<-your realm->|

If "you" decide to send a datagram to "Me", you ask DNS to translate my name to my address, and among others you get my address as seen by ISP1. You send it from your realm's addressing: your source address is in a ULA. It crosses the DMZ to ISP2, changing to ISP2's prefix; we now have a datagram from somewhere in ISP2 to ISP1. For ISP2, it is simply "somewhere in ISP1"; in ISP1 it is specifically somewhere at my domain. It crosses my DMZ, and now it is from your PA address to my ULA address.

If we're going to use the world "realm", I think the area the realms cover is the same as you describe, and which I show above. However, "Me" is reachable by "You" at my PA address. There is no question of non-reachability, and no question of dynamic session state in the translation.

I think in a NAT66 world, you would have to extend the definition to say that an IPv4 prefix realm is about reachability as you say; an IPv6 realm is one in which the same prefix pair is used in both the source and destination address in an IPv6 datagram.

On Apr 29, 2010, at 12:15 AM, Schwarz Albrecht wrote:

> We got a definition for "IPv4 realm", based on RFC 2663 (but also RFC 3103).
> Both RFC's are IPv4 oriented, not providing an explicit definition  for an "IPv6 realm".
>  
> This question might be related to NAT66, because the IPv4 realm concept is originating from NAT44.
>  
> Does anyone know a correspondent definition/reference for IPv6 realm?
>  
> If not, I'd like to offer an initial proposal for discussion, - a common realm term for IPv4 and IPv6: 
> 
> (IPv4 or IPv6 address) realm: is defined as a set of addresses, which share all a common prefix, that are mutually reachable (thus, within a single IP routing domain).
>  
> Note: "IPv6 realm" definition based on the GLOBAL UNICAST ADDRESS format (§ 2.5.4/RFC 4291) because this is a hierarchical format using a "global routing prefix", which is assigned to a "site" (i.e. sth like a REALM).
> Comments would be appreciated,
> Albrecht
> _____
> RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations
> 2.1. Address realm or realm
> 
> 
> 
> 
>    An address realm is a network domain in which the network addresses
>    are uniquely assigned to entities such that datagrams can be routed
>    to them. Routing protocols used within the network domain are
>    responsible for finding routes to entities given their network
>    addresses. Note that this document is limited to describing NAT in
>    IPv4 environment and does not address the use of NAT in other types
>    of environment. (e.g. IPv6 environments)
> 
>     
> RFC 3103 Realm Specific IP: Protocol Specification
> 3.  Terminology
>    Private Realm
> 
>       A routing realm that uses private IP addresses from the ranges
>       (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
>       [
> RFC1918
> ], or addresses that are non-routable from the Internet.
> 
>    Public Realm
> 
>       A routing realm with unique network addresses assigned by the
>       Internet Assigned Number Authority (IANA) or an equivalent address
>       registry.
> 
> _______________________________________________
> nat66 mailing list
> nat66@ietf.org
> https://www.ietf.org/mailman/listinfo/nat66

http://www.ipinc.net/IPv4.GIF