Below, with [PTT].
On 24/11/2014 1:13 PM, Simon Perreault wrote:
On Mon, Nov 24, 2014 at 11:30 AM, Tom Taylor <[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?
[PTT] Different usage, just the necessary information in the description
clause. Anyway, I prefer the suggestion at the end.
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?
[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.
Simon
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
