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