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? > 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
