Hi, Eric,
I have the same understanding with you about the behaviour of
SARP, but I do not think that it is NAT, I think that it is more similar to
Gateway.
Let’s reuse your figure,
IP-S
IP-D
ES-1 T-W T-E
ES-2
[MAC-S] ------(?) (MAC-W)------(MAC-E) (?)------[MAC-D]
S-A S-B
S-C
Now, let’s assume that T-W is the gateway for ES-1 and T-E is
the gateway for ES-2,
For traffic going West-to-East:
In the ARP model, T-W responds to an ARP request from ES-1 for IP-D with MAC-W.
In traditional IP routing model:
o ES-1 sends a frame with (D-MAC=MAC-W, S-MAC=MAC-S) to T-W;
o T-W translate S-MAC=MAC-S to S-MAC=MAC-W, translate D-MAC=MAC-W
to D-MAC=MAC-E, and forwards the frame (otherwise as is) to T-E
o T-E translates D-MAC=MAC-E to D-MAC=MAC-D according to IP-D, and
forwards the frame to ES-2.
Now, do we think that the gateway T-W and T-E also provide MAC-NAT function?
I think that SARP use some mechanism like MAC-Gateway to hide hosts’ MAC
address from outer data centers. It does not purely work via simple address
mapping (for example, IP NAT or PNAT), it works with help IP-MAC host-route
like the IP gateway, so I think it is not MAC-NAT.
Hewen
(In the first try to response your mail, the response is blocked by the IETF
mail system because "Message body is too big: 52215 bytes with a limit of 40 KB
", so I have to retry after deleting some previous info; If IETF mail system
finally let the first response go, please ignore it, sorry the duplicated mail)
From: Eric Gray [mailto:[email protected]]
Sent: Friday, October 11, 2013 12:26 AM
To: Zhenghewen; [email protected]
Subject: RE: [Int-area] FW: Re: Call for adoption of draft-nachum-sarp
Hewen,
Please. I did not object to this without having read the
draft. According to
what I read, this is not only MAC-NAT, but it is messy MAC-NAT.
At the 50,000 foot level, the proposal uses a "proxy" that
returns a different
MAC address than that corresponding to the IP address of the destination. The
proxy
then replaces the destination MAC address (D-MAC) of Ethernet frames in transit
with
the MAC address that corresponds to the IP destination.
This D-MAC replacement is half of a MAC translation (or, as
many folks would
know it, MAC-NAT). It is only "half" of a translation, because the current
draft only
requires translation of the D-MAC, leaving the source MAC address (S-MAC) as is
– at
least optionally, and at this proxy.
Going down to the 10,000 foot level, the proposal attempts to
mimic scaling
advantages of using a hierarchical backbone – using a flat (non-hierarchical)
network
approach – based on an interesting (read complicated) asymmetrically-symmetric
form of MAC-NAT where an exchange between two IP destinations is forwarded
across the flat-backbone using two separate proxies where D-MAC replacement
(AKA – translation) takes place in each direction as the frame leaves the
backbone
(i.e. – the D-MAC in each direction is translated by the remote proxy on the
other
side of the mocked-up backbone).
The same proxy (now on the near-side of the mocked up backbone)
MAY
(optionally in the current draft) translate the S-MAC of returning frames. If
this is
done, and the far-side proxy then translates the D-MAC of the same frame, you
have completed a full MAC-NAT at two separate locations in the network.
If S-MAC translation is not done, there is a significant
potential for causing
confusion to L2 networking components that learn forwarding information from
the S-MAC of in-transit frames, and host (or virtual machines) that learn
ARP-cache
information. The draft assumes that this can be worked around by turning
learning
capabilities off – but this may not be possible.
The details of the idea (as I understand them) can be
pictorially represented
as follows:
IP-S
IP-D
ES-1 T-W T-E
ES-2
[MAC-S] ------(?) (MAC-W)------(MAC-E) (?)------[MAC-D]
S-A S-B
S-C
Where:
(ES-1, ES-2) = End-Station (1, 2)
MAC-S is the MAC address of ES-1, the source of a subsequent
frame to ES-2
IP-S is the IP(v4/v6) address of ES-1
MAC-D is the MAC address of ES-2, the destination for the above
frame
IP-D is the IP(v4/v6) address of ES-2
(S-A, S-B, S-C) = Segments (A, B, C)
MAC-W is the MAC address of T-W that is visible on S-B (the
draft does not
say whether or not T-W has a different MAC
address associated with
its interface onto S-A)
MAC-E is the MAC address of T-E that is visible on S-B (the
draft does not
say whether or not T-E has a different MAC
address associated with
its interface onto S-C)
For traffic going West-to-East:
In the ARP model, T-W responds to an ARP request from ES-1 for IP-D with MAC-E
(which then becomes visible on S-A).
In the translation model:
o ES-1 sends a frame with (D-MAC=MAC-E, S-MAC=MAC-S);
o T-W MAY translate S-MAC=MAC-S to S-MAC=MAC-W, if bridge-learning
is used
on S-B, and forwards the frame (otherwise as is) to T-E
(note that this is what it says, but IMO the S-MAC translation
MUST occur);
o T-W translates D-MAC=MAC-E to D-MAC=MAC-D, and forwards the frame
to
ES-2 (note that – at this point the frame MUST have S-MAC=MAC-W
or ES-2 will
replace the earlier ARP cache entry with one associating MAC-S
with IP-S – and
this is not what the draft currently says [so it is essentially
broken]).
The last step above requires looking further into the frame to peek at
destination IP
address IP-D, and then looking MAC-D up in its local (S-C) ARP cache.
For traffic going East-to-West, behavior is analogous but reversed.
So, the draft does propose MAC-NAT – either partial, or complete (with partial
being
worse than complete).
--
Eric
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
