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 protected]> 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. > > 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
