Subject: [BEHAVE] NAT MIB: index for retrieval of address maps

From: Tom Taylor <[email-masked]>
Date: Mon, 24 Nov 2014 11:30:33 -0500

The published version -11 of the NAT MIB module indexes address maps by 
NAT instance, internal realm, and internal address. This works fine, I 
think, except in the CGN case where packets originated by the subscriber 
come in by way of tunnels. Take DS-Lite as an example.

In the case of DS-Lite, the realm actually defines an IPv6 numbering 
space -- the reserved IPv4 address 192.0.0.2 appearing as the source of 
packets originated by the subscriber certainly won't be unique over the 
realm, making nonsense of the definition of realm as defining a 
numbering space.

I see two possible ways to present the address map in the MIB module. 
One is to keep things as they are, but add a note that the operator may 
want to filter on subscriber index (which is part of the mapping 
information) to select the information they really want. If they are 
starting with the IPv6 tunnel source address, they have to go to the 
subscriber table to get the corresponding subscriber index, then use 
that to filter the map data.

The other possible solution is to index the map data by the "internal 
realm address" (which would be the IPv6 tunnel source address) and 
present the internal packet source address (which would be the reserved 
192.0.0.2) separately in the mapping table. Except in the case of 
tunneling, the two addresses will be the same, so there is redundancy in 
most cases. However, the workflow for tracing back from a tunnel source 
address would be simplified.

Comments? Preferences?

Tom Taylor

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Nov 2014 13:13:25 -0500

On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <[email-masked]>
wrote:

> In the case of DS-Lite, the realm actually defines an IPv6 numbering space
> -- the reserved IPv4 address 192.0.0.2 appearing as the source of packets
> originated by the subscriber certainly won't be unique over the realm,
> making nonsense of the definition of realm as defining a numbering space.
>

The definition of realm should be changed so that the tuple (internal
address, subscriber index) is unique.

Actually I argued in the beginning that each DS-Lite subscriber should have
its own realm. That would make for a simpler model, but it turns out that
that maps poorly to current implementations. That's why we have subscriber
indexes now.

I see two possible ways to present the address map in the MIB module. One
> is to keep things as they are, but add a note that the operator may want to
> filter on subscriber index (which is part of the mapping information) to
> select the information they really want. If they are starting with the IPv6
> tunnel source address, they have to go to the subscriber table to get the
> corresponding subscriber index, then use that to filter the map data.
>

Not sure what you mean. Are you suggesting a different *usage*, or actual
changes to the MIB?

> realm address" (which would be the IPv6 tunnel source address) and present
> the internal packet source address (which would be the reserved 192.0.0.2)
> separately in the mapping table. Except in the case of tunneling, the two
> addresses will be the same, so there is redundancy in most cases. However,
> the workflow for tracing back from a tunnel source address would be
> simplified.
>

Why not just add the subscriber index to the index?

Simon

---

From: Tom Taylor <[email-masked]>
Date: Mon, 24 Nov 2014 18:38:57 -0500

Below, with [PTT].

> Not sure what you mean. Are you suggesting a different *usage*, or actual
[PTT] Different usage, just the necessary information in the description 
clause. Anyway, I prefer the suggestion at the end.
> Why not just add the subscriber index to the index?

[PTT] Bearing in mind the application scenarios we listed the other day, 
I figured subscriber wouldn't always be supported. However, I've already 
defined a Natv2SubscriberIndexOrZero for the map, so it won't do any 
harm to add it to the map index.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 27 Nov 2014 13:50:01 -0500

I have thought this through a bit more. One of the results is a 
resolution between the need to define an IPv6 realm covering some group 
of DS-Lite-served subscribers and your intuition that there should be a 
realm per subscriber. In fact, both are true simultaneously, but the 
scope of the IPv4 realm is limited to the tunnel in which it operates, 
so it isn't very interesting.

What I propose at this point is as follows:

natv2AddressMapInternalRealm OBJECT-TYPE
     SYNTAX SnmpAdminString (SIZE(0..32))
     MAX-ACCESS not-accessible
     STATUS current
     DESCRIPTION
         "Realm to which the internal address belongs. In most cases
          this is the realm defining the address space of the packet
          being translated. However, in the case of DS-Lite [RFC
          6333], this realm defines the IPv6 outer header address
          space, while it is the inner IPv4 packet header that is
          remapped to the external address and realm. The
          corresponding IPv4 realm is restricted in scope to the
          tunnel, so there is no point in identifying it. Similarly,
          the mapped IPv4 address will normally be the well-known
          value 192.0.0.2, or at least lie in the reserved
          192.0.0.0/29 range, and hence is not particularly
          interesting.

          If natv2AddressMapSubscriberIndex in this table is a valid
          subscriber index (i.e., greater than zero), then the value
          of natv2AddressMapInternalRealm MUST be identical to the
          value of natv2SubscriberRealm associated with that index."
     REFERENCE
         "DS-Lite: RFC 6333, Section 5.7 for well-known addresses
          and Section 6.6 on the need to have the IPv6 tunnel address
          in the NAT mapping tables."
     ::= { natv2AddressMapEntry 2 }

natv2AddressMapInternalAddressType OBJECT-TYPE
     SYNTAX InetAddressType
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
         "Address type in the header of packets on the
          interior side of this mapping. Any value other than ipv4(1)
          or ipv6(2) would be unexpected.

          In the DS-Lite case, the address type is ipv6(2). The
          mapping in that case is considered to be from the
          combination of the IPv6 tunnel source address and the
          well-known IPv4 inner source address (which is not presented
          in this table) to the external address."
     REFERENCE
         "DS-Lite: RFC 6333, Section 5.7 for well-known addresses
          and Section 6.6 on the need to have the IPv6 tunnel address
          in the NAT mapping tables."
     ::= { natv2AddressMapEntry 3 }

natv2AddressMapInternalAddress OBJECT-TYPE
     SYNTAX InetAddress
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
         "Source address of packets originating from the interior
          of the association provided by this mapping.

          In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel
          source address. In this case, the mapping is considered to
          be from the combination of the tunnel source address and the
          well-known IPv4 inner source address (which is not presented
          in this table) to the external address."
     REFERENCE
         "DS-Lite: RFC 6333, Section 5.7 for well-known addresses
          and Section 6.6 on the need to have the IPv6 tunnel address
          in the NAT mapping tables."
     ::= { natv2AddressMapEntry 4 }

Tom Taylor

On 24/11/2014 1:13 PM, Simon Perreault wrote:
>
> On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The published version -11 of the NAT MIB module indexes address maps
>     by NAT instance, internal realm, and internal address. This works
>     fine, I think, except in the CGN case where packets originated by
>     the subscriber come in by way of tunnels. Take DS-Lite as an example.
>
>     space -- the reserved IPv4 address 192.0.0.2 appearing as the source
>     of packets originated by the subscriber certainly won't be unique
>     over the realm, making nonsense of the definition of realm as
>     defining a numbering space.
>
>
> Actually I argued in the beginning that each DS-Lite subscriber should
> have its own realm. That would make for a simpler model, but it turns
> out that that maps poorly to current implementations. That's why we have
> subscriber indexes now.
>
>     I see two possible ways to present the address map in the MIB
>     module. One is to keep things as they are, but add a note that the
>     operator may want to filter on subscriber index (which is part of
>     the mapping information) to select the information they really want.
>     If they are starting with the IPv6 tunnel source address, they have
>     to go to the subscriber table to get the corresponding subscriber
>     index, then use that to filter the map data.
>
>
> Not sure what you mean. Are you suggesting a different *usage*, or
> actual changes to the MIB?
>
>     The other possible solution is to index the map data by the
>     "internal realm address" (which would be the IPv6 tunnel source
>     address) and present the internal packet source address (which would
>     be the reserved 192.0.0.2) separately in the mapping table. Except
>     in the case of tunneling, the two addresses will be the same, so
>     there is redundancy in most cases. However, the workflow for tracing
>     back from a tunnel source address would be simplified.
>
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Nov 2014 13:56:21 -0500

Ok so if I understand correctly, you replace the IPv4 --> IPv4 address
mapping with the IPv6 --> IPv4 address mapping in the case of DS-Lite.

If that's right, then I don't see how it could work. There is not
necessarily such an IPv6 --> IPv4 address mapping. The internal 192.0.0.0/29
addresses could be mapped to different external IPv4 addresses. Or maybe I
misunderstood your proposal...

Simon

On Thu, Nov 27, 2014 at 1:50 PM, Tom Taylor <[email-masked]>
wrote:

> I have thought this through a bit more. One of the results is a resolution
> between the need to define an IPv6 realm covering some group of
> DS-Lite-served subscribers and your intuition that there should be a realm
> per subscriber. In fact, both are true simultaneously, but the scope of the
> IPv4 realm is limited to the tunnel in which it operates, so it isn't very
> interesting.
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 27 Nov 2014 14:06:34 -0500

In the first place, you replace the IPv4 --> IPv4 mapping with
{IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333.

Beyond that, the text I gave refers to a single mapping in the address 
map table. For different external IPv4 external addresses, you would be 
looking at different mapping instances.

Tom

On 27/11/2014 1:56 PM, Simon Perreault wrote:
> necessarily such an IPv6 --> IPv4 address mapping. The internal
> 192.0.0.0/29 <http://192.0.0.0/29> addresses could be mapped to
> different external IPv4 addresses. Or maybe I misunderstood your proposal...
>
> Simon
>
...

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Nov 2014 14:11:38 -0500

> {IPv6, IPv4} --> IPv4 mapping. See Section 5.6 of RFC 6333.

I understand that, but I don't see how the proposed MIB text does that.

Beyond that, the text I gave refers to a single mapping in the address map
> table. For different external IPv4 external addresses, you would be looking
> at different mapping instances.
>

Can you please give an example with numbers showing how a DS-Lite address
mapping would be represented in the MIB?

Thanks,
Simon

---

From: Tom Taylor <[email-masked]>
Date: Thu, 27 Nov 2014 14:23:05 -0500

Just to set the agenda: the definition of the address mapping table entry:

natv2AddressMapEntry OBJECT-TYPE
     SYNTAX Natv2AddressMapEntry
     MAX-ACCESS not-accessible
     STATUS current
     DESCRIPTION
         "Mapping from internal to external address."
     INDEX { natv2AddressMapInstanceIndex,
             natv2AddressMapInternalRealm,
             natv2AddressMapInternalAddressType,
             natv2AddressMapInternalAddress }
     ::= { natv2AddressMapTable 1 }

Natv2AddressMapEntry ::=
     SEQUENCE {
         natv2AddressMapInstanceIndex       Natv2InstanceIndex,
         natv2AddressMapInternalRealm       SnmpAdminString,
         natv2AddressMapInternalAddressType InetAddressType,
         natv2AddressMapInternalAddress     InetAddress,
         natv2AddressMapExternalRealm       SnmpAdminString,
         natv2AddressMapExternalAddressType InetAddressType,
         natv2AddressMapExternalAddress     InetAddress,
         natv2AddressMapSubscriberIndex     Natv2SubscriberIndexOrZero
     }

Now some example numbers:

natv2AddressMapInstanceIndex       = 1
natv2AddressMapInternalRealm       = "DS-Lite Group 5"
natv2AddressMapInternalAddressType = ipv6(2)
natv2AddressMapInternalAddress     = 2001:db8:0:1::1
natv2AddressMapExternalRealm       = "global4"
natv2AddressMapExternalAddressType = ipv4(1)
natv2AddressMapExternalAddress     = 192.0.2.1
natv2AddressMapSubscriberIndex     = 487231

This entry would be indexed by the combination of

{ 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 }

Tom

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Nov 2014 14:38:51 -0500

> { 1, "DS-Lite Group 5", ipv6(2), 2001:db8:0:1::1 }

Ok, so far this is what I expected. I see a mapping from 2001:db8:0:1::1 to
192.0.2.1. However, in DS-Lite that mapping does not necessarily exist. For
example, you could have these two mappings to different external addresses
simultaneously:

{ 2001:db8:0:1::1, 192.0.0.1 } --> 192.0.2.1
{ 2001:db8:0:1::1, 192.0.0.2 } --> 192.0.2.2

Note that this is the same subscriber, same IPv6 address, but different
internal IPv4 addresses mapped to different external IPv4 addresses. As you
can see there is no unique mapping IPv6 --> IPv4.

Simon

---

From: Tom Taylor <[email-masked]>
Date: Thu, 27 Nov 2014 14:44:57 -0500

Below.

> can see there is no unique mapping IPv6 --> IPv4.
[PTT] If this is true for a single NAT instance, then I have to add the 
mapped address to the table. I see Section 5.7 is open on the subject, 
so I'll do so.

Thanks,
Tom