Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

From: Xu Xiaohu <[email-masked]>
Date: Tue, 01 Dec 2009 17:07:31 +0800

> -----邮件原件-----
> 发件人: Cameron Byrne [mailto:[email-masked]]
> 发送时间: 2009年12月1日 15:32
> 收件人: Xu Xiaohu
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu <[email-masked]> wrote:
> >
> >
> >> -----邮件原件-----
> >> 发件人: [email-masked] [mailto:[email-masked]] 代表
> >> Cameron Byrne
> >> 发送时间: 2009年12月1日 1:19
> >> 收件人: [email-masked]
> >> 抄送: [email-masked]; Xu Xiaohu
> >> 主题: Re: [BEHAVE] proprietary implementation v.s standardised
> protocols//re:
> >> draft-xu-behave-nat-state-sync-00
> >>
> >> On Mon, Nov 30, 2009 at 4:54 AM,  <[email-masked]>
> >> wrote:
> >> >
> >> > Dear Cameron,
> >> >
> >> > The issue you are describing is more about load distribution rather than
> NAT
> >> state sync.
> >>
> >> Correct, i believe we can best provide service availability in the
> >> macro network with DNS64 controlled load distribution.  NAT sync in
> >> the macro network faces too many challenges to be useful
> >
> > Do you want to use DNS64 to achieve NAT redundancy while realizing
> load-balancing? Do you mean offering the IPv6 host another prefix64 by DNS64
> if the NAT box for the previous prefix crashes?
> >
> > Xiaohu
> 
> Yes, I want DNS64 to facilitate NAT64 redundancy from a macro-network
> perspective while also providing load-sharing. Load sharing and
> redundancy are frequently coupled (web server farms, sip proxies,
> anycast DNS servers ...).  This solutions is only focused on AAAA
> query responses to an IPv6-only host from a DNS64, which in my
> use-case is the most common scenario.  Other use-cases do not interest
> me as much and may better fit a well know anycast prefix64.

In order to use the correct prefix64 in synthesizing AAAA records, the DNS64 should be able to determine which prefix64 is available by some means, e.g., exchanging messages with NAT64, or sending probe packets to a given IPv4 host within the IPv4 Internet by using different prefix64s.

BTW, once the NAT box for a given prefix fails, would the communications using that prefix be interrupted till the corresponding AAAA records in the DNS caches of IPv6 hosts expire?

Xiaohu

> >> > I agree with the requirement you have (BTW, similar solutions exist for
> the
> >> selection of the outbound proxy SIP) but this may be easy to implement with
> >> stateless NATxy rather than stateful one since the path MUST be symmetric
> (the
> >> same NAT device must be crossed) and appropriate routing actions should be
> >> undertaken to redirect the traffic to the appropriate NATxy device. If you
> have
> >> a fully distributed NATxy and all advertise the same IPv4 net, then the
> symmetry
> >> requirement is difficult to meet. Not to mention that the load should be
> >> controlled in both sides of the NAT.
> >> >
> >>
> >> Unfortunately, i have yet to find an useful application for stateless
> >> NATxy in my network.  The NAT44 i have deployed today require
> >> multiplexing many users behind a small pool public IP address.
> >> Changing the source from IPv4 to IPv6 will face the same limitation
> >> that requires multiplexing many users behind a few IPv4 addresses and
> >> consequently requires a stateful multiplexed solution.
> >>
> >> Regarding symmetrical flows, I don't really understand your comment.
> >> I don't support the idea of macro network state sync, and i do see
> >> that people who try to deploy that will have a symmetry issue.
> >>
> >> My expectation is that each stateful NAT64 (local 1+1) with a unique
> >> PREF64 will advertise a unique IPv4 prefix, so the flows are always
> >> symmetric.  The entire network has many stateful NAT64 (local 1+1) and
> >> the translation load and resiliency is solved by distributing these
> >> autonomous building blocks of capacity and availability throughout the
> >> network.
> >>
> >> > Cheers,
> >> > Med
> >> >
> >> >
> >> > -----Message d'origine-----
> >> > De : Cameron Byrne [mailto:[email-masked]]
> >> > Envoyé : jeudi 26 novembre 2009 18:43
> >> > À : BOUCADAIR Mohamed NCPI/NAD/TIP
> >> > Cc : Xu Xiaohu; Brian E Carpenter; [email-masked]
> >> > Objet : Re: [BEHAVE] proprietary implementation v.s standardised protocols
> >> //re: draft-xu-behave-nat-state-sync-00
> >> >
> >> > On Thu, Nov 26, 2009 at 12:04 AM,  <[email-masked]>
> >> wrote:
> >> >>
> >> >> Dear Cameron,
> >> >>
> >> >> This may be true for 1+1 redundancy schemes, but what about N+1 ones?
> >> >
> >> > In other threads i have proposed using multiple  NAT64 / PREF64 pairs
> >> > handed out by the DNS64, and having feedback from the NAT64 to the
> >> > DNS64 to communicate health of NAT64 box such that the PREF64 can be
> >> > taken out of rotation if needed by the DNS64.  This is how global site
> >> > load balancing works today for web sites and CDNs.  I do expect this
> >> > type of implementation to have NAT64 in 1+1 for local instant fault
> >> > tolerance and the DNS64 to be a more macro level recovery and load
> >> > sharing technique
> >> >
> >> > If can't get it into the standard, i can get a vendor to do it.  And,
> >> > if i can't get a vendor to do it i can probably rig it myself with a
> >> > perl script to SNMP poll the NAT64 for health and load and reset the
> >> > DNS64 config automatically to redirect traffic from bad PREF64 /
> >> > NAT64s to good PREF64 NAT64s
> >> >
> >> > I know the tricks that global site load balancing does are not pure,
> >> > but my perpective is that this is the reality of the internet, it is
> >> > the only way google, facebook, yahoo can scale.  It is the only way
> >> > NAT64 can scale linearly as a system of hardware building blocks and
> >> > survive at a macro level.
> >> >
> >> > Cameron
> >> >
> >> >>
> >> >> Cheers
> >> >> Med
> >> >>
> >> >>
> >> >> -----Message d'origine-----
> >> >> De : Cameron Byrne [mailto:[email-masked]]
> >> >> Envoyé : mercredi 25 novembre 2009 18:50
> >> >> À : Xu Xiaohu
> >> >> Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; Brian E Carpenter; [email-masked]
> >> >> Objet : Re: [BEHAVE] proprietary implementation v.s standardised
> protocols
> >> //re: draft-xu-behave-nat-state-sync-00
> >> >>
> >> >> On Wed, Nov 25, 2009 at 2:05 AM, Xu Xiaohu <[email-masked]> wrote:
> >> >>>
> >> >>>> -----邮件原件-----
> >> >>>> 发件人: [email-masked] [mailto:[email-masked]] 代
> 表
> >> >>>> [email-masked]
> >> >>>> 发送时间: 2009年11月13日 14:41
> >> >>>> 收件人: Brian E Carpenter; [email-masked]
> >> >>>> 主题: Re: [BEHAVE] draft-xu-behave-nat-state-sync-00
> >> >>>>
> >> >>>>
> >> >>>> Dear all,
> >> >>>>
> >> >>>> I guess that the question should be asked priori to yours:
> >> >>>>
> >> >>>> Do we let vendors define their proprietary solutions or does the IETF
> >> define
> >> >>>> a solution based on standardised protocols to achieve reliable state
> >> >>>> synchronisation?
> >> >>>
> >> >>> For a small enterprise network, maybe it's acceptable to deploy two or
> more
> >> NAT boxes purchased from the same vendor for redundancy. However, for a large
> >> ISP network or large enterprise network, it is not reliable enough. For
> example,
> >> an abnormal packet will cause the router OS to crash, it is not absolutely
> >> acceptable. Hence I believe the standardization of NAT redundancy is
> necessary.
> >> >>>
> >> >>
> >> >> In the large scale NAT44 we run today, all vendors have 1+1
> >> >> proprietary state sync.  They also sync configuration and other OAM
> >> >> elements over this sync channel.  I do not think it is at all required
> >> >> for vendors to have a standard state sync.  If I deploy multiple
> >> >> vendors for NAT, i will keep the 1+1 pairs of the same vendor and use
> >> >> different vendor 1+1 pairs for higher level network topology driven
> >> >> redundancy, not local state synchronization.
> >> >>
> >> >> Cameron Byrne
> >> >> Principal Engineer
> >> >> T-Mobile USA
> >> >>
> >> >>> Xiaohu
> >> >>>
> >> >>>
> >> >>>> From a service provider perspective, I'd like to see a solution with
> IETF
> >> stamp
> >> >>>> so as to be included in our RFPs/analysis. Vendors are then free to
> propose
> >> >>>> more reliable solutions, if any, compared to the one standardised by
> IETF.
> >> >>>>
> >> >>>> Cheers,
> >> >>>> Med
> >> >>>>
> >> >>>>
> >> >>>> -----Message d'origine-----
> >> >>>> De : [email-masked] [mailto:[email-masked]] De la
> part
> >> de
> >> >>>> Brian E Carpenter
> >> >>>> Envoyé : vendredi 13 novembre 2009 02:55
> >> >>>> À : [email-masked]
> >> >>>> Objet : [BEHAVE] draft-xu-behave-nat-state-sync-00
> >> >>>>
> >> >>>> My question about this draft is whether there is available code and
> >> >>>> implementation experience with SCSP, which was defined in 1998.
> >> >>>>
> >> >>>> If there isn't code and experience, since it is a quite complex design,
> >> I would
> >> >>>> be a bit worried.
> >> >>>>
> >> >>>> On the other hand, I believe that something of the complexity of SCSP
> is
> >> >>>> absolutely required to provide reliable synchronisation.
> >> >>>> There is no simple, lightweight way to do this reliably.
> >> >>>>
> >> >>>>     Brian
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Behave mailing list
> >> >>>> [email-masked]
> >> >>>> https://www.ietf.org/mailman/listinfo/behave
> >> >>>>
> >> >>>> *********************************
> >> >>>> This message and any attachments (the "message") are confidential and
> >> intended
> >> >>>> solely for the addressees.
> >> >>>> Any unauthorised use or dissemination is prohibited.
> >> >>>> Messages are susceptible to alteration.
> >> >>>> France Telecom Group shall not be liable for the message if altered,
> >> changed
> >> >>>> or falsified.
> >> >>>> If you are not the intended addressee of this message, please cancel
> it
> >> >>>> immediately and inform the sender.
> >> >>>> ********************************
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Behave mailing list
> >> >>>> [email-masked]
> >> >>>> https://www.ietf.org/mailman/listinfo/behave
> >> >>>
> >> >>> _______________________________________________
> >> >>> Behave mailing list
> >> >>> [email-masked]
> >> >>> https://www.ietf.org/mailman/listinfo/behave
> >> >>>
> >> >>
> >> >> *********************************
> >> >> This message and any attachments (the "message") are confidential and
> >> intended solely for the addressees.
> >> >> Any unauthorised use or dissemination is prohibited.
> >> >> Messages are susceptible to alteration.
> >> >> France Telecom Group shall not be liable for the message if altered,
> changed
> >> or falsified.
> >> >> If you are not the intended addressee of this message, please cancel it
> >> immediately and inform the sender.
> >> >> ********************************
> >> >>
> >> >>
> >> >
> >> > *********************************
> >> > This message and any attachments (the "message") are confidential and
> >> intended solely for the addressees.
> >> > Any unauthorised use or dissemination is prohibited.
> >> > Messages are susceptible to alteration.
> >> > France Telecom Group shall not be liable for the message if altered, changed
> >> or falsified.
> >> > If you are not the intended addressee of this message, please cancel it
> >> immediately and inform the sender.
> >> > ********************************
> >> >
> >> >
> >> _______________________________________________
> >> Behave mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/behave
> >
> > _______________________________________________
> > Behave mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/behave
> >

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 05:42:46 -0500

> BTW, once the NAT box for a given prefix fails, would the communications using that prefix be interrupted till the corresponding AAAA records in the DNS caches of IPv6 hosts expire?

This is exactly why each "box" is in fact many boxes whose state is 
synchronized.

Handling the complete failure of a set of such boxes is really up to the 
operator and doesn't need to be standardized, in my opinion. Many custom 
actions would need to be taken in such a case.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Dec 2009 09:10:20 -0800

> In order to use the correct prefix64 in synthesizing AAAA records, the DNS64 should be able to determine which prefix64 is available by some means, e.g., exchanging messages with NAT64, or sending…

Yes, i have suggested that the DNS64 SNMP poll the NAT64 to understand
its health and load (CPU, memory, active connections, ...).

> BTW, once the NAT box for a given prefix fails, would the communications using that prefix be interrupted till the corresponding AAAA records in the DNS caches of IPv6 hosts expire?

Yes, the host would have to re-query to the DNS64 unless we wanted to
provide the host with multiple AAAA responses with different addresses
synthesized from different pref64

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Dec 2009 09:11:32 -0800

On Tue, Dec 1, 2009 at 2:42 AM, Simon Perreault
<[email-masked]> wrote:
>> In order to use the correct prefix64 in synthesizing AAAA records, the
>> DNS64 should be able to determine which prefix64 is available by some means,
>> e.g., exchanging messages with NAT64, or sending probe packets to a given
>> IPv4 host within the IPv4 Internet by using different prefix64s.
>>
>> BTW, once the NAT box for a given prefix fails, would the communications
>> using that prefix be interrupted till the corresponding AAAA records in the
>> DNS caches of IPv6 hosts expire?
>

agreed.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 09:16:33 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Xu Xiaohu
> Sent: Tuesday, December 01, 2009 1:08 AM
> To: 'Cameron Byrne'
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] proprietary implementation v.s 
> standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
> 
> 
> 
> > -----邮件原件-----
> In order to use the correct prefix64 in synthesizing AAAA 
> records, the DNS64 should be able to determine which prefix64 
> is available by some means, e.g., exchanging messages with 
> NAT64, or sending probe packets to a given IPv4 host within 
> the IPv4 Internet by using different prefix64s.
> 
> BTW, once the NAT box for a given prefix fails, would the 
> communications using that prefix be interrupted till the 
> corresponding AAAA records in the DNS caches of IPv6 hosts expire?

It's not just the AAAA records getting cached.  It's also the 
applications that have done their getaddrinfo() and now have the
IPv6 address in their internal datastructures.  There is no lifetime
for that, and very very few applications pay any attention to the
TTL of the AAAA record.  Applications expect the IPv6 address to 
be fixed and to be valid as long as they need it.

This means that to provide reasonable service, 'backup' NAT64 
has to serve the same Pref64 as the now-failed NAT64, and 
routing needs to send those IPv6 packets towards the 'backup' 
NAT64 (typically accomplished on a LAN with HSRP or VRRP).

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 13:01:10 -0500

> be fixed and to be valid as long as they need it.

How hard should NAT64 try to accommodate broken applications?

These applications would fail in many other cases that don't involve NAT64.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 10:39:57 -0800

> [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Tuesday, December 01, 2009 10:01 AM
> To: [email-masked]

My point is that it shouldn't make things worse.  If the functioning
NAT64's prefix changes and the old prefix no longer works, that makes
things worse -- it effectively causes IPv6 addresses to change.  That
breaks not just applications that are sensitive to IP address changes, 
but also existing TCP sessions.  SCTP handles IP address changes
better, but there is scant deployment of SCTP yet (due to many 
reasons).

> These applications would fail in many other cases that don't 

But IPv4 addresses on today's Internet don't change much, especially
while connections are up.  When they do, yes, applications break.  
That's part of the whole Location/Identifier split problem.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 14:15:40 -0500

> better, but there is scant deployment of SCTP yet (due to many 

I don't understand where you're going.

There are two kinds of breakage:

1. One NAT64 box in a cluster* dies. No impact beyond the fact that you now have
a dead box that needs replacing.

2. A whole cluster dies. This is not pain-free, and it's not designed to be.
Suddenly, you need to redirect all clients to the new Pref64::/n. There are
known issues with that, but this event will happen rarely enough that it's worth
the risk.

If you're really afraid of breakage #2, you have to use bigger clusters. But
that has disadvantages too. It ends up being an operational issue. Tradeoffs, etc.

Another idea: have another cluster "take over" the prefix of the dead one. Use
routing to redirect clients to the new cluster. Tradeoffs, etc., again.

My point is that #2 doesn't need standardization. The solutions are diverse and
everyone will be dealing with it differently. On the other hand, #1 is a well
understood problem, with a well understood solution, with various proprietary
incarnations in use right now (hint! hint!).

* Cluster = A set of synchronized NAT64 boxes sharing a single Pref64::/n.

Cheers,
Simon

---

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Dec 2009 19:26:29 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault

Yes but it's not the apps that are broken, it's the sockets
API that's broken (getaddrinfo and its predecessor gethostbyname
don't return it).  Applications just call APIs and are agnostic
as to whether the name gets resolved using DNS, hosts file,
mDNS, LLMNR, NetBIOS over TCP, or whatever else.  The only applications
that pay attention to TTL are ones that only support DNS and not
other protocols, and generally either implement DNS themselves 
or call DNS-specific APIs that expose a TTL.

So yes NAT64 should try (to the extent that is practical) 
to accommodate apps that don't pay attention to TTL, since that's
99.99% of all applications.

-Dave

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Dec 2009 14:40:18 -0500

> 99.99% of all applications.

Either that, or we should get to work on changing the APIs.  Since I
predict heat death of the universe first, I agree with Dave.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 12:02:09 -0800

> Sent: Tuesday, December 01, 2009 11:16 AM
> To: Dan Wing
> Cc: [email-masked]

Agreed.  I think we were just mis-communicating between
the two types of breakage.  I had thought you were describing
breakage (1) as needing (or wanting) a new Pref64.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 15:07:11 -0500

> predict heat death of the universe first, I agree with Dave.

No, let's change the APIs to make NAT64 work!

Just kidding... we all agree on that. But what was the point again?

The point was that you cannot fail over clients from one Pref64::/n to another
because applications will remember addresses. This is true, to some extent. If
it was 100% true then you wouldn't be able to change anything once you publish a
DNS record. In reality, hosts are rebooted, applications are restarted, and web
pages are reloaded. So you have some wiggle room.

Failing over to another Pref64::/n is an unlikely event. It means that something
*really bad* happened. (See my other email about the two types of breakage.) Any
partial fix is better than just shutting of the Internet to your customers. If
it means they have to close Outlook and restart it, so be it.

Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Dec 2009 15:43:34 -0500

> pages are reloaded. So you have some wiggle room.

"Reloading a web page" often doesn't help.  I have experience of at
least one popular browser that reaches down and remembers the A record
for the target host.  Then the magic DNS load balancer decides to pull
that IP out of the mix, and stuff starts breaking randomly.  (One of
the many ways in which DNS load balancers don't work the way their
deployers seem to think they do.)   That said,

> partial fix is better than just shutting of the Internet to your
> customers. If it means they have to close Outlook and restart it, so
> be it.

I completely agree here.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Dec 2009 14:05:23 -0800

> it means they have to close Outlook and restart it, so be it.

100% agree.  Members in a cluster failing can locally be resolved
without bouncing the Pref64.  If entire cluster fails, this is very
unlikely but catastrophic, i just want a fail safe that can work
*mostly*, and if the networks really broke, asking a user to reboot
their phone and be fixed in 1 minute is better than waiting for a 4
hour RMA or  guy with backhoe to fix fiber or electrician to arrve
,...

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 10:32:03 +1100

> > customers. If it means they have to close Outlook and restart it, so

getaddrinfo() is designed to be extensible.  Lets exercise that extensiblity.
Resolution methods w/o a TTL get some default value set (0 or 10 mins) or
a flag which says it is not set.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 02 Dec 2009 09:48:03 +0800

Simon
> Perreault
> 发送时间: 2009年12月2日 3:16
> 收件人: Dan Wing
> 抄送: [email-masked]
> 1. One NAT64 box in a cluster* dies. No impact beyond the fact that you
now
> that has disadvantages too. It ends up being an operational issue.
Tradeoffs,
> etc.
> My point is that #2 doesn't need standardization. The solutions are
diverse
> and

Does that mean a set of NAT64 boxes within a cluster should be from a single
vendor? If so, how to deal with the case that some abnormal packets cause
NAT boxes (using the same OS) within a cluster to crash simultaneously due
to a bug with that OS?

Xiaohu

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 20:52:02 -0500

On 12/01/2009 08:48 PM, Xu Xiaohu wrote:
>> On the other hand, #1 is a well
> vendor?

No! I was hinting exactly to the contrary. We should standardize NAT64
state synchronization.

Simon

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 02 Dec 2009 09:58:09 +0800

> 发送时间: 2009年12月2日 6:05
> 收件人: Simon Perreault

Ask a user or ask a huge amount of users?

By the way, if one uses one of those mechanisms defined in draft-wing-behave-learn-prefix, other than DNS64, to synthesize IPv6 addresses, does that mean the DNS server or the DHCP server should also dynamically detect the availability of each prefix64?

Xiaohu

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 18:06:53 -0800

... 
> NAT boxes (using the same OS) within a cluster to crash 
> simultaneously due to a bug with that OS?

The vendor fixes the bug.

The operational complexity of running two NATs, from two different vendors, is
very high:  different CLIs, different alarming/alerting (e.g., SYSLOG, SNMP,
per-session NAT logging), different features (e.g., IPsec Passthru, SCTP),
different implementation of features (e.g., TCP MSS adjustment, fragmentation
[timeouts?  how much memory dedicated to reassembly?  out-of-order packets
supported?]), bandwidth and throughput (Mbps, pps),  make it too hard to
operate both NATs.

To my knowledge, sites do not run two different implementations of DNS servers
(e.g., ISC BIND and InfoBlox, or Microsoft and Unbound) where both DNSs back
up each other.  Like NAT, DNS needs to be rock-solid reliable, and a single
packet could take out a DNS server.

-d

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 13:38:06 +1100

> packet could take out a DNS server.

Actually lots of sites use multiple vendors for DNS.   That being
said there is not of lot of state to share between DNS servers.

DHCP servers on the other had need to share lots of state.  I don't
believe the failover draft (draft-ietf-dhc-failover-12) reached a
conclusion even though we implement most (all?) of it in our DHCP
servers.

Mark

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 18:40:09 -0800

...
> Ask a user or ask a huge amount of users?

All the affected users.

> By the way, if one uses one of those mechanisms defined in 
> draft-wing-behave-learn-prefix, other than DNS64, to 
> synthesize IPv6 addresses, does that mean the DNS server or 
> the DHCP server should also dynamically detect the 
> availability of each prefix64?

Whatever hands out the prefix (DNS, IPv6 router advertisements, 
DHCPv6) should hand out a functioning prefix.  Providing a 
non-functioning prefix is harmful.

The same is true of a DHCP server providing the IP address of 
DNS servers, NTP servers, and suchlike.  If a DHCP server hands
out IP addresses for broken (or dead) servers, it is harmful.

Does that need to be stated, though?

-d

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 13:54:18 +1100

> non-functioning prefix is harmful.

Actually it shouldn't be.  If a prefix doesn't work it it like a
router being down.  The machines are just not reachable.
 
> out IP addresses for broken (or dead) servers, it is harmful.

Which is why DHCP is designed to hand out multiple ones so that
individual failures are not a issue.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 19:41:43 -0800

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, December 01, 2009 6:38 PM
> To: Dan Wing
> Cc: 'Xu Xiaohu'; 'Simon Perreault'; [email-masked]
> > To my knowledge, sites do not run two different 
> implementations of DNS server
> > s

So they would update each other when one receives, say, a DNS UPDATE?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 19:43:32 -0800

> Sent: Tuesday, December 01, 2009 6:54 PM
> To: Dan Wing
> Cc: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'; [email-masked]

Not being reachable is what I would define as 'harmful'.

> individual failures are not a issue.

draft-wing-behave-learn-prefix-05, not yet published, allows
multiple prefixes as well.  It also removes the unicast/ASM/SSM
specifics and relies on the IPv6 prefix itself to declare if
its unicast/ASM/SSM.

-d

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Dec 2009 20:37:04 -0800

> The vendor fixes the bug.

100% agree.  The counter to Xu Xiaohu's point is what happens when
vendor X sends a buggy sync update to vendor Y, and now vendor Y
crashes.... ok.  We traded one unlikely (but real) bad situation for
another unlikely but bad situation.

> supported?]), bandwidth and throughput (Mbps, pps),  make it too hard to

100% agree.

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 02 Dec 2009 12:39:14 +0800

> -----邮件原件-----
> 发件人: Dan Wing [mailto:[email-masked]]
> 发送时间: 2009年12月2日 10:40
> 收件人: 'Xu Xiaohu'; 'Cameron Byrne'; 'Simon Perreault'
> 抄送: [email-masked]
> 主题: RE: [BEHAVE] proprietary implementation v.s
> non-functioning prefix is harmful.

Agree. In fact, with the IPv6 RA approach, the gateway router could
dynamically learn the available prefix64 through IGP extension (e.g., Router
Information LSA in OSPF).

Xiaohu

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Dec 2009 23:45:48 -0500

I believe we have agreed that we want to support the configuration of 
multiple stateful NAT64s in a cluster sharing state (using the same 
prefix, backing each other up / sharing load / ... ).

While it is true that one can deploy that with solutions from a single 
vendor, it seems natural and consistent with the rest of what we do here 
that we want to allow folks to build such a cluster using devices from 
different vendors.  Arguing about why an operator might or might not do 
that is a waste of time.  Some will want multiple vendors.  Some will 
want a single vendor.  Some will want the ability to migrate to a new 
vendor.

For the IETF therefore, the protocol for the state sharing seems a 
sensible thing to standardize.

Yours,
Joel

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 15:51:12 +1100

> So they would update each other when one receives, say, a DNS UPDATE?

UPDATEs are forwarded to the master server that then applies the
update and sends out NOTIFY messages to say the zone contents have
changed.  The slaves then do a IXFR request triggered by the NOFIFY.

		             serial 1		           serial 1
client ->    UPDATE       -> slave -> FORWARED UPDATE    -> master 
							   serial 2
client <- UPDATE RESPONSE <- slave <- UPDATE RESPONSE    <- master
			     slaves <- NOTIFY (serial 2) <- master
			     slaves -> NOTIFY RESPONSE   -> master
			     slaves -> IXFR (serial 1)   -> master
			     slaves <- IXFR RESPONSE     <- master
			     serial 2

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 02 Dec 2009 13:12:23 +0800

> 发送时间: 2009年12月2日 12:37

Aha, as long as the router from vendor X is still available, that would be OK. Maybe you would say later how about if router X kills itself after making router Y crash. Just a joke!  ^_^

Xiaohu

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 21:14:47 -0800

> Sent: Tuesday, December 01, 2009 8:51 PM
> To: Dan Wing
> UPDATEs are forwarded to the master server 

They're both master servers; you can't invoke DNS's master/secondary
concept here.  :-)

-d

> that then applies the

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 21:20:36 -0800

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Tuesday, December 01, 2009 8:46 PM
> To: Cameron Byrne
> Cc: Dan Wing; [email-masked]; Xu Xiaohu

FWIW, I will be asking my co-chair to decide WG consensus to move 
forward with NAT synchronization.

-d

> implementations of DNS servers

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 16:49:08 +1100

> Not being reachable is what I would define as 'harmful'.

You don't, in general, pull hosts from the DNS because a router is
down.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 16:55:14 +1100

> They're both master servers; you can't invoke DNS's master/secondary

UPDATE doesn't support multi-master, it hasn't been specified.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Dec 2009 22:02:52 -0800

> You don't, in general, pull hosts from the DNS because a router is

If i understand your statement right, you do pull host from the a
given DNS server upon failure if it is anycast DNS

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 22:05:13 -0800

> Sent: Tuesday, December 01, 2009 9:55 PM
> To: Dan Wing

I know.

Then the multi-vendor mixed DNS environment you had described
earlier isn't happening:  one DNS is master, the others are
secondary.  That's different from the active/standby of NAT64
being proposed, where the standby NAT64 takes over completely and
fully for the now-deceased (e.g., crashed) NAT64, and is now
a fully-functioning node.

With a secondary taking over for a master, it is not a fully
funtional node (it can't accept UPDATEs, for example, and 
changing its serial number on a zone file will be forgotten
when the master comes back alive).  Only the master is fully 
functional.

Seems different to me.

-d

---

From: <[email-masked]>
Date: Wed, 2 Dec 2009 07:53:41 +0100

Dear Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mercredi 2 décembre 2009 03:07
À : 'Xu Xiaohu'; 'Simon Perreault'
Cc : [email-masked]
Objet : Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

... 

Med: Except for the configuration operations, the remaining features should be the same, since both implementations should met the SP's requirement.
Furthermore, having both the primary and that backup nodes from the same vendor induces other unpredictable problems (and therefore long unavailability period). We experienced that kind of problems/behaviour with L2 nodes, it may be the case for NATxy boxes too.

-d

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Dec 2009 18:13:55 +1100

In message <[email-masked]>, Camer
on Byrne writes:
> >> > > > > 100% agree. =A0Members in a cluster failing can locally
> >> > be resolved
> >> > > > > without bouncing the Pref64. =A0If entire cluster fails,
> >> > this is very
> >> > > DHCPv6) should hand out a functioning prefix. =A0Providing a
> >> > Actually it shouldn't be. =A0If a prefix doesn't work it it like a
> >> > router being down. =A0The machines are just not reachable.
> >>

No.  Normally you leave the address records in and let the client
determine if the host is reachable or not.  You never want to remove
all addresses as that makes the host disappear and that changes
recovery strategies.

> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org
> >

---

From: <[email-masked]>
Date: Wed, 2 Dec 2009 08:16:10 +0100

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Joel M. Halpern
Envoyé : mercredi 2 décembre 2009 05:46
À : Cameron Byrne
Cc : [email-masked]; Xu Xiaohu; Dan Wing
Objet : Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

Med: I fully agree.

Yours,
Joel

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Dec 2009 09:37:22 -0500

> given DNS server upon failure if it is anycast DNS

Not in the anycast deployments I've been involved with, but maybe I
don't understand your remark properly.

Normally, when you anycast DNS, you have one host address in the DNS,
but you announce different routes to that host in the routing system.
You should be able to observe this with different looking glasses for
(for example) the host a0.org.afilias-nst.info.  Note that I'm no
longer involved with the operation of that network, so I am not
entirely sure it still works that way, but I'd be surprised if it
changed that much.

Maybe this isn't what you were talking about?  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 2 Dec 2009 14:45:33 -0500

I agree with Dan in the operational complexity and said so in a different
post pointing issues such as different memory footprints, timers,
configuration, etc.

I think before we jump in and work on standardizing a protocol we should
exercise caution, take a step back and understand the challenges and scope
of the work. 

I suggest the IETF works on a document discussing what kind of information
is synched between two NAT boxes/cards of the same vendor today and
assumptions around platform (Memory, CPU, throughput), configuration, timers
(TCP, UDP, fragmentation, etc), keep-alives, and others that go with that.

Thanks,

Reinaldo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 02 Dec 2009 18:19:23 -0500

> (TCP, UDP, fragmentation, etc), keep-alives, and others that go with that.

How is this relevant to NAT64?

What we need to consider is NAT64 state and not care about NAT44. 
Otherwise it will be a tar pit.

And I don't think we need any other separate document. This is a well 
understood problem.

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 2 Dec 2009 22:14:51 -0500

> How is this relevant to NAT64?

Maybe we are not talking about the same thing so let's work through an
throughput example and if we decide we are talking about the same thing we
can discuss the other issues I pointed out in the light of NAT64.

Let's assume you have NAT-A and NAT-B from different vendors. NAT-A is
processing packets for 3 NAT sessions and as master have synched these 3 NAT
sessions to NAT-B.

If NAT-A fails and NAT-B takes over, how can you guarantee that NAT-B will
be able to handle these sessions in terms of packets per second?

Thanks,

Reinaldo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 03 Dec 2009 07:15:35 -0500

> be able to handle these sessions in terms of packets per second?

Assuming s/NAT/NAT64/g...

This is an operational issue. You just ensure that this will work when 
you buy and deploy A and B. Check spec sheets, chat with vendors, 
perform tests, etc.

What's your point?

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 3 Dec 2009 16:43:29 -0500

First of all you state that all NAT64 implementations will be the same
because the standard is new. Therefore  I did the following exercise:

I re-read a _single_ section of NAT64 (3.2.4.  ICMP Query Session Handling).
I found that developers have the following choices (and this does not go
into implementation details):

* Local Security Policy can drop ICMPv6 packets (yes/no)
* Local Security Policy can drop ICMPv6 packets configurable per
  interface/rule/etc (yes/no for each one)
* ICMPv6 lifetime can be configurable (yes/no)
* ICMPv6 lifetime can be configurable within a certain range (yes/no)
* ICMPv6 lifetime can be configurable with a granularity of ms/seconds/etc
  (yes/no)
* ICMPv4 message will be sent back to sender (yes/no/configurable)
* ICMPv4 message will be sent back to sender per configuration
  interface/nat rule/etc (yes/no each one)
* ICMPv4 message will be sent back to sender in case of filtering
  (yes/no/configurable)
* ICMPv4 message will be sent back to sender per configuration
  (interface/rule/etc)
* ICMPv4 lifetime can be configurable (yes/no)
* ICMPv4 lifetime can be configurable within a certain range (yes/no)
* ICMPv4 lifetime can be configurable with a granularity of ms/seconds/etc
  (yes/no)
 
And do not even get me started in generic address-filtering behavior which
is much more complex and have more implementation choices.

And this the way things are because different providers have different
networks and provider service to customer with different needs.

Second, you indicate that operational complexity is something on the side.

Providers are interested in Service Continuity as a solution. Operational
complexity cannot be dismissed off hand with 'This is an operational issue'.
Several people made this point clear in the list.

But, let's take this further:

Can you elaborate on which tests need to be done in order to guarantee that
this scenario will work between two different vendors?

Of course after the provider go through all the tests for this single and
only scenario, if NAT64-A or NAT64-B needs to be upgraded, it is not
guarantee that things will work again. Software from different vendors
evolve differently, are EOLed differently, change behavior differently.

Finally, If you pin down all specific behavior you need within all possible
permutations of different vendors, weigh the operational cost of a
multi-dimensional testing to find two boxes that can provide the High
Availability with the NAT behavior you need, I think you will find out that
NAT64-A and NAT64-B are made by the same vendor.

Thanks,

---

From: Simon Perreault <[email-masked]>
Date: Thu, 03 Dec 2009 17:00:24 -0500

Reinaldo Penno wrote, on 2009-12-03 16:43:
> because the standard is new.

This is exaggerated. I think that because NAT64 is *well specified* (compared
with NAT44), chances are higher that a standard state sync protocol will work.

>   interface/rule/etc (yes/no for each one)> * ICMPv4 message will be sent back to sender (yes/no/configurable)

These do not affect state.

> * ICMPv4 lifetime can be configurable with a granularity of ms/seconds/etc

These will need to be taken into account by an eventual state sync protocol. For
example, we could have a phase at connection establishment where these
parameters are explicitly stated and we make sure that the two are configured
with the same values. Or we could do dynamic configuration in master/slave fashion.

I don't see this as anything more than a requirement for a state sync protocol.

> is much more complex and have more implementation choices.

Please do! This is helpful design work! ;)

> networks and provider service to customer with different needs.

I don't see how this is relevant.

> Second, you indicate that operational complexity is something on the side.

Again, this is exaggerated. Of course you need NAT devices that are spec'ed
correctly. I don't see how this affects a state sync protocol.

> this scenario will work between two different vendors?

So you mean that because vendor A and vendor B will not swear that each other's
stuff works fine, we should only use stuff from a single vendor? This statement
has nothing to do with NATs and applies in many other cases you know...

> NAT64-A and NAT64-B are made by the same vendor.

That could very well be true. It is also often the case for e.g. BGP speakers.
But some people like to run stuff from multiple vendors. And it works, and it
has advantages and disadvantages. Tradeoffs, etc.

Thanks,
Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 5 Dec 2009 03:27:33 -0500

A few comments inline...

> These do not affect state.

Why not? If a certain mapping on NAT64-A does not send ICMPv4 packets back
for unsolicited sessions and another mapping does, this behavior must remain
the same on the fail-over box.

NAT state is the mapping state + ICMP behavior (discussed above) + filtering
behavior + timer settings (discussed below for ICMP) + log behavior
(yes/no/format) + others not discussed. Each of these can be different for
different NAT entries.

> So you mean that because vendor A and vendor B will not swear that each
> other's This 
> statement

Some people made the opposite case and it brings to some of the basics. NAT
operational complexity is high and therefore brings special requirements to
the table. Based on your statement it seems you think there are similar
cases. 

Can you give an example that has the same characteristics as hot-standby for
NATs based on the few things that were discussed? If there are we should
look into how hot-standy across different devices & vendors was achieved in
that case.

---

From: Simon Perreault <[email-masked]>
Date: Sat, 05 Dec 2009 06:50:36 -0500

On 12/05/2009 03:27 AM, Reinaldo Penno wrote:
> If a certain mapping on NAT64-A does not send ICMPv4 packets back

This is arguable. IMHO, this behaviour could be different without 
negative impact in many situations.

But the point is that the state sync protocol is completely unconcerned 
with this.

> (yes/no/format) + others not discussed. Each of these can be different for

We have different definitions of state it seems.

ICMP behaviour, filtering behaviour, timer settings, log behaviour, and 
others do not vary over time. (Or we could impose the constraint that 
the state sync connection be renegotiated when they do vary.)

The state sync protocol is only concerned with stuff that varies over 
time, i.e. bindings and sessions. That's it.

> the table. Based on your statement it seems you think there are similar

"NAT operational complexity is high" is a blanket statement. For 
example, nowadays most everyone has a NAT at home without even knowing it.

> look into how hot-standy across different devices&  vendors was achieved in
> that case.

I don't know. But are you saying we shouldn't do something because 
nobody has done it before?

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Dec 2009 02:15:05 -0500

> negative impact in many situations.

This is a vague statement. Can you please elaborate which situations are
these without negative impact?

In my experience there are usually negative impacts ranging from from legal
requirements, DDoS & security and last but not least performance.

> time, i.e. bindings and sessions. That's it.

Can you explain what exactly and how is your definition of 'vary over time'?
When a NAT binding is created with certain parameters, do you foresee the
same NAT binding varying over time before the session is over?

I certainly foresee that the same private address can get a different
bindings when it goes to different destinations over time. But then it can
also get a different ICMP handling, filtering, logging and timer behavior.
Therefore this state also needs to be synched with each new different
binding. 

> example, nowadays most everyone has a NAT at home without even knowing it.

Right, one vendor, one box, one interface in-out, box wide knobs for most
NAT behavior. Is that how you see service providers NAT boxes?

Because that would explain where you are coming from in relation to NAT
state, filtering, etc.

Thanks,

Reinaldo

PS: One thing NAT home devices have that is very useful is UPnP and NAT-PMP
(but that is being implemented in some large NAT boxes). Thinking about that
makes me wonder if the protocol will synch dynamic NAT port forwarding state
established through UPNP and NAT-PMP across boxes.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Dec 2009 08:29:25 -0500

> these without negative impact?

The situation: Two NATs, state synced, one sending ICMP errors and the other not.

To elaborate further: Suppose I'm talking about a small/medium enterprise with
the two NATs in sync sitting at the border of the Internet and their LAN. There
are people working in the LAN, with, say, web browsers. They absolutely don't
care about the difference in ICMP behaviours.

> requirements, DDoS & security and last but not least performance.

Sure, I don't disagree. But there are tons of other cases where it doesn't matter.

So we could want the sync protocol to negotiate or not these differences in
behaviour.

> same NAT binding varying over time before the session is over?

Example: You power up the NAT and put it in service. It has no
bindings/sessions. As packets traverse it, bindings and sessions get created,
deleted, etc. So the binding and session tables vary over time. Also known as
"dynamic".

The behaviours such as "sends ICMP errors" do not vary. They are always the same
(or at least, remain constant during the lifetime of a NAT state sync session).
Therefore the state sync protocol has nothing to do with them. It may need to be
restarted to renegotiate their values if they change, but that's it. Also known
as "static".

> Therefore this state also needs to be synched with each new different

No. This is not dynamic state, it's static configuration. The static
configuration needs to be the same, or could also be negotiated at the
beginning. It is completely separate from state sync and does not run under the
same constraints. For example, the state sync protocol needs to be very
efficient. But to negotiate static configuration this constraint is relaxed.

If you want to do this "at random" then yes it would be dynamic and need to be
synchronized. But I suggest this be out of scope.

> NAT behavior. Is that how you see service providers NAT boxes?

I suppose that the correct answer is "no."

Note that a NAT state sync protocol would be useful to much more than just
service providers.

> Because that would explain where you are coming from in relation to NAT

I'm feeling that this discussion is becoming less constructive.

> established through UPNP and NAT-PMP across boxes.

Sure, why not? It's just a matter of propagating changes to the binding/session
tables.

To recap our discussion:

- An eventual state sync protocol would need an init phase where static
configuration and behaviours would be negotiated.

- The level to which the static stuff needs to be similar (or made similar) will
differ in different cases.

- After the negotiation is successful, only dynamic state updates will be
propagated.

Is this right? Does anything else need to be said at this point?

Thanks,
Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Dec 2009 13:57:34 -0500

Thanks for the reply. Comments inline...

> care about the difference in ICMP behaviours.

I'm not sure about the people in the LAN but the enterprise operating the
NAT boxes cares. 

> restarted to renegotiate their values if they change, but that's it. Also

If all you send to the slave NAT is the private (IP address, port) protocol,
public (IP address and port), how will the slave box know which ICMP and
filtering behavior to apply to a certain NAT binding?

Example:  

In vendors' 1 box the NAT mapping is

SRC IP 2000::1, SRC PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port
2000 

That mapping was a result of a 'rule match' in which amongst many rules
there was one saying:

From: incoming interface 1, SRC IP 2000::/96 SRC PORT 10000-10500, protocol
UDP
To: outgoing interface 2, DST IP 2001::2,
NAT pool: 200.1.1.20-200.1.1.30,
Log: outgoing, binary
Timeout 30 seconds,
ICMP: no ICMPv4 for unsolicited
Filtering: allow incoming from 100.1.1.1-100.1.1.100, syslog
Port: Port parity.

The part that you proposing to synch is the mapping ( SRC IP 2000::1, SRC
PORT 1000, UDP -> Public IP 200.1.1.1, Public SRC Port 2000 ), correct?

So, how will NAT slave determine all other behavior for each different
mapping as it receives the NAT state from the master?

> configuration and behaviours would be negotiated.

Scope clarification question based on what you said above:  Since each
vendors' boxes are configured differently are you saying you will come up
with a configuration scheme common and acceptable by all vendors as part of
this effort so negotiation (configuration and behaviors) can succeed?

> - After the negotiation is successful, only dynamic state updates will be

See question in beginning with example.

> Is this right? Does anything else need to be said at this point?

A few things come to mind as discussed.

* Need to mention how the protocol will synch UPNP and NAT-PMP info
* How the protocol will synch ALG info.
* IPSEc and other VPN/VRF issues
* others that will discuss later.

Thanks,

Reinaldo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Dec 2009 19:52:52 -0500

> I'm not sure about the people in the LAN but the enterprise operating the

Actually in my mind I was referring to the people running the network. I 
think most of the time they will not care. I agree that someone could 
care, and that there should be a way to negotiate this as part of the 
protocol.

> PORT 1000, UDP ->  Public IP 200.1.1.1, Public SRC Port 2000 ), correct?

Correct.

(BTW, very good example!)

> mapping as it receives the NAT state from the master?

By ensuring that both NATs are configured with the same static 
configuration?

> this effort so negotiation (configuration and behaviors) can succeed?

Yes, it is very important to get the scope right.

I think the scope should be limited to the choices that are present in 
the NAT64 spec. In your example above, the following would be out of scope:

- Logging
- Filtering (Not talking about NAT filtering behaviour. The example 
above is part of firewall functionality, not NAT.)

How about that?

> * Need to mention how the protocol will synch UPNP and NAT-PMP info

You mean static configuration or just the bindings? I don't see how 
bindings would be synchronized differently that those created by 
outbound connection initiation.

> * IPSEc and other VPN/VRF issues

In my mind the protocol would need to be extensible. The base spec would 
focus on NAT64. Extensions could be written for ALGs/IPsec/...

Thanks,
Simon