I know there is minimal chance of a response at this time of year, but
it would be nice to get on with this work.
Up to now, the SYSLOG-based NAT logging document has identified
individual subscriber sites using identifiers the nature of which is
indicated in the text below. In addition, it has used realm identifiers.
We are now proposing to rationalize the situation by having the realm
absorb all of the other information. In the case of DS-Lite, however,
this has an operational impact: administrative action is required to
assign a realm identifier to every individual subscriber site served by
a DS_Lite tunnel.
Is this reasonable, or should realms apply at a more aggregate level?
The text that follows would replace existing text in the SYSLOG NAT
document talking about realms and subscriber site identifiers. The MIB
and IPFIX logging documents would also align themselves with this text.
Tom Taylor
---------------------
A realm identifies an IP numbering space. A NAT session always maps
between an interior and an exterior realm. In simple NAT configurations,
it may be possible to identify a default interior realm and/or a default
exterior realm for all sessions.
Address pools are associated with specific exterior realms.
It is necessary to define multiple realms when multiple IP numbering
spaces exist. A NAT may distinguish realms in its mapping tables in
different ways, depending on implementation and deployment. Examples
follow shortly. For external presentation, however, logging will use the
realm number. The NAT MIB [reference] provides a mapping between realm
number and an administratively-provided realm name, and may provide
further information relating that to other information corresponding
more closely to the representation by the NAT in its internal tables.
A NAT recognizes the incoming realm by three basic means:
- at the physical level, by incoming interface;
- at layer 2, by incoming VLAN, VLAN stack, or VPN;
- at layer 3:
-- by PE-based VPN based on incoming destination address and
possibly other packet header information and forwarded
using VPNs based either on BGP/MPLS or Virtual Routers, or
-- by incoming tunnel, typical of various transition technologies.
[RFC 4026] is useful to sort out the various VPN concepts.
The rest of this description deals with specific cases of layer 3
tunnels associated with transition technologies. The administrator has
to be aware of these descriptions for the purpose of assigning realm
names to the entities involved, while the NAT designer needs to
understand how to implement both NAT operation in the cases described
and the mapping between the identifiers concerned and the realm identifier.
DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It
features an encapsulating/decapsulating service combined with a very
large scale NAT44 in the provider network (the Address Family
Transitional Router, AFTR). Every outbound IPv4 packet has a source
address within the reserved 192.0.0.0/29 range. As a result, Section 6.6
of [RFC 6333] has the following advice on NAT operation for DS-Lite:
"6.6. Extended Binding Table
The NAT binding table of the AFTR element is extended to include the
source IPv6 address of the incoming packets. This IPv6 address is
used to disambiguate between the overlapping IPv4 address space of
the service provider customers."
In the DS-Lite case, therefore, the NAT identifies realm from the IPv6
address of the encapsulating tunnel from the customer device.
Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC
6674]. It is based primarily on the aggregation of traffic from a
particular access gateway through a single softwire to the AFTR. Within
that tunnel, a context identifier identifies the flow of traffic from a
particular customer device. The IPv4 source address in outbound packets
thus becomes irrelevant for routing, whether or not it is unique.
In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from
the combination of softwire identifier and context identifier. Section 6
of [RFC 6674] describes the combinations of identifiers that might be
deployed, depending on the operator circumstances. Sections 3 and 4 of
[RFC 6674] go into the details of NAT operation for Gateway-Initiated
DS-Lite.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
