Subject: [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging

From: Tom Taylor <[email-masked]>
Date: Sat, 21 Dec 2013 13:52:23 -0500

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.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 22 Dec 2013 02:24:03 +0000

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

Reading section 6, the incoming realm identifier refers/includes the IPv6 address of the encapsulating tunnel (from the customer device). Why is an admin action required?

Cheers,
Rajiv

Sent from my Phone

On Dec 22, 2013, at 12:22 AM, "Tom Taylor" <[email-masked]> wrote:

> 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> 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.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Tom Taylor <[email-masked]>
Date: Sun, 22 Dec 2013 11:56:18 -0500

Sorry, section 6 of which document? Section 2.3.1 of the SYSLOG document

http://www.ietf.org/id/draft-ietf-behave-syslog-nat-logging-05.txt

is the most relevant to this discussion. What is termed a generalized 
internal address in that section represents the prior point of view: 
that the realm has to be qualified with further information to identify 
the subscriber site uniquely. The fact is that the characterization in 
that section is incomplete -- the qualifying information required can 
also include VLAN and VRF identifiers.

I guess the proposed new text effectively incorporates the generalized 
internal address information into the realm name, so the administrative 
action required would be something that does that automatically.

Tom

On 21/12/2013 9:24 PM, Rajiv Asati (rajiva) wrote:
>> 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.
>
> Reading section 6, the incoming realm identifier refers/includes the
> IPv6 address of the encapsulating tunnel (from the customer device).
> Why is an admin action required?
>
> Cheers, Rajiv
>
> Sent from my Phone
>
....

---

From: Tom Taylor <[email-masked]>
Date: Wed, 25 Dec 2013 09:05:26 -0500

Further analysis shows it was a foolish idea to try to save a few bytes 
per log at the expense of other complications. Sorry for the noise.

Tom Taylor