> My main concern here is with the O&M implication of dynamically
> created and used softwires, which do not run any routing protocol and
> there is no IETF protocol or management framework which could be used
> to verify the correct operation of these tunnels.
In fact, we have over a decade of experience with softwires, implemented as
MPLS tunnels. We also have many years of experience with softwires
implemented as L2TPv3 tunnels, and I believe there are also deployments of
softwires implemented as GRE tunnels. So it's a little late to claim that
these constructs pose insuperable management difficulties.
All that's really new here is that the framework for signaling the tunnels
and for determining which packets get tunneled has been stated in a general
way, and the use of softwires is discussed in the context of a v6/v4
Internet, rather than in the context of L3VPN.
The application of OAM to softwires (particularly when realized as MPLS
LSPs) has been quite extensively discussed over the years and I don't think
anything new needs to be mandated by the framework document.
> In S 5 (this is also bordering on architectural issue):
This leads to the following softwires deployment
restriction: if a BGP Capability is defined for the case
in which an E-IP NLRI has an I-IP NH, all the AFBRs in a
given transit core MUST advertise that capability.
> ... is there any way an implementation could verify if this deployment
> restriction holds or not?
I don't think a service provider with an I-IP core would start offering E-IP
transit service unless all its AFBRs were capable of providing the service.
This not only includes having the appropriate BGP capabilities, but also the
appropriate hardware/software capabilities to do the encapsulation and
decapsulation, support for E-IP and I-IP on appropriate interfaces, etc.
One could imagine configuring the BGP speakers (including route reflectors)
so that IBGP connections are not accepted unless some particular set of BGP
capabilities are advertised, but that's only one small piece of the overall
set of deployment requirements.
> The document does not describe MTU and fragmentation/reassembly issues in
> the core network at all. In this kind of service my assumption is that you
> need to support 1500B packets at ingress when DF-bit is set or the packet is
> IPv6. Discussion in RFC4459 seems applicable here. The operational
> solution to this problem is the requirement to provision the core network
> with larger MTUs so that all 1500B+encapsulation overhead can be supported
> throughout the core. This needs to be discussed in the text.
This is a fair point. We should state a requirement that the core be able
to support handle, without fragmentation, the result of encapsulating
"maximum size" E-IP packets.
> At some point, a client might want to upgrade to dual stack. Then,
> client-interface may use both E-IP and I-IP. This solution should be
> applicable then as well
Depending on policy, one might or might not want to do, e.g., v6/v6 or v4/v4
encapsulation. However, covering these cases is not within the scope of the
WG charter.
> I.e., the longest-prefix matching is no longer sufficient with
> softwires (i.e.: when deciding whether a packet to a particular E-IP
> destination prefix should be tunneled through a softwire or forwarded
> natively).
I'm not sure what made you think that longest-prefix matching is not
sufficient.
> Basically what you have in AFBR's is BGP routing table with E-IP prefixes
> with I-IP nexthops (and these I-IP nexthops are populated using IGP through
> physical interfaces), and you can't associate I-IP nexthops with softwires
> tunnel interface(s) because the next-hops must use BGP over the physical
> network.
> If I interpret this correctly, this is a substantial difference in the
> forwarding paradigm and requirements, and should be more clearly described.
> I wonder, how you would go about implementing this, in any case?
This forwarding paradigm has been implemented and deployed since about 1997,
and you can find many implementations where packets are sent through tunnels
(whether MPLS, L2TPv3, or GRE) even though the tunnel endpoints are not
routing adjacencies.
> the corresponding IPv4-mapped IPv6 address for G is not a multicast
> address because it does not start with FF00::/8, and I suspect as a result
> all implementations will treat such a G address as a unicast address. I
> guess one could fix this by standardizing a group mapping to use some
> multicast prefix under ff00::/8 and encode the v4 address in the bottom
> bits.
Yikes, good catch. Probably we should just call out the need for such a
standard to be produced.
> missing standardization [in the area of tunneling multicasts]
In the unicast area, most of the technology needed is already standardized
or in LC, hence the framework document makes normative references. In the
multicast area, the situation is different, and the framework document lays
out options without making normative references to specified technology.
> Have these two things [BGP next hop resolution and stacking of
> encapsulations] been specified somewhere? This calls for a reference.
I think "recursive route resolution" and "stacking encapsulations" are "terms
of the art" which do not need to be defined in this document, but for which
there is not a standard reference.
> security issues
> ---------------
However, attacks of this sort can result in policy violations. The
authorized transmitting endpoint(s) of a softwire may be following a
policy according to which only certain payload packets get sent
through the softwire. If unauthorized nodes are able to encapsulate
the payload packets so that they arrive at the receiving endpoint
looking as if they arrived from authorized nodes, then the properly
authorized policies have been side-stepped.
> .. I believe this could result in two kinds of attacks which could be
> emphasized better (more below) Above uses "policy violations" which
> may be read to refer to a policy described in Section 7. For example,
> the focus of the second quoted sentence is odd -- and makes this seem like
> an issue in transmitting endpoints while to me the major issue seems to be
> unauthorized endpoints.
The problem referred to is that if unauthorized nodes masquerade as
authorized transmitting endpoints, there may be a way to side-step the
authorized policies. I'm not quite sure what you are objecting to here.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
