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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
