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 protected]
<mailto:[email protected]>> 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.
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?
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.
Why not just add the subscriber index to the index?
Simon
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
