Subject: RE: Multihoming with NAT

From: Serkan Cil <[email-masked]>
Date: Mon, 2 Dec 2002 12:06:11 -0500

Hi,

If we do not insist on IP multiplexing it is still possible to support MH
behind a NAT.
NAT boxes can do static address mapping between the global
and local address spaces. This does not require any information (port etc.)
from the protocol carried in IP packet. It is a simple address mapping
operation.
Also NAT can work with a pool of global addresses and a pool of local
addresses.
So following scenario seems possible if we configure the nat1 and nat2 to do
just the address mapping. We are basically reserving global addresses IP1'
and IP2' for 
IP1 and IP2 mapping. "host" needs to send the INIT with hostname param. 
(which is mapped to IP1' and IP2' in DNS or else)

     IP1           IP1'  
 host -------nat1 ------ISP1
  |
  +----------nat2-------ISP2
     IP2           IP2'

Serkan

> -----Original Message-----
> From: Randall Stewart (cisco) [mailto:[email-masked]]
> Sent: Thursday, November 28, 2002 8:21 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Multihoming with NAT
> 
> 
> Manish:
> 
> 
> I think you miss my point...
> 
> To have an effective NAT arrangement where multi-homing is going (i.e.
> you want no single point of failure):
> 
> 
> host -------nat1 ------ISP1
>   |
>  +----------nat2-------ISP2
> 
> Having
> 
> host -----net1----NAT-------ISP
>  |                          |
> +----------net2----+
> 
> makes two different single points of failure .. aka the
> NAT itself as well as your ISP
> 
> Moving the two ISPs to talk to one NAT does not
> help since you still have a single point of failure.. and it does not
> work anyway.. Most nats can only handle translating to one 
> address... I have
> this arrangment in my own router/nat box... It has two ISP's 
> hooked to 
> it and
> I must run two different instances of the nat software.. one for one 
> interface
> and the other for the second... these two do NOT know how to 
> communicate
> about the two networks...This is what is hard.. you must get 
> the NAT's to
> talk to each other and reserve the SAME port on two seperate networks
> and setup state. There may be some nat software out there that can
> handle two networks but this is the rarity if it even exits...
> 
> Yes it can work.. without this.. but not with multihoming in the 
> picture.. except maybe
> behind the nat (my second drawing).. and in this case it does 
> not really 
> help you
> that much ... and one can just do the send the INIT with no 
> addresses... 
> I don't
> see how you could get any benefit of the two internal 
> addresses without 
> external
> addresses to go with them... Remember a SCTP association is 
> only on ONE port
> and a NAT uses the ports to find the state... So my second 
> picture gets 
> NO benefit
> and the second requires intra-nat communications... And if 
> you really wanted
> it done right you would need to have the nats on seperate boxes with a
> intra-nat communication protocol so you would have no single point of 
> failure..
> not one nat controlling two addresses... which I don't know 
> if it even 
> exits....
> 
> R
> 
> 
> [email-masked] wrote:
> 
> >
> >hi
> >
> >No! you don't need a SCTP aware NAT, lets suppose NAT has 
> two addresses, then
> >both these addresses can be used for the  association. The 
> packets sent by the
> >peer to any of these addresses will be routed to the sctp 
> host which has got a
> >single address. So u have a multihomed association without 
> the host having more
> >than one address.
> >about the misbehaving routers, i'ld like say that its the 
> multihoming that comes
> >to rescue when you have diffrent addresses belonging to 
> different networks, So
> >while one network is not in good health the packets can take 
> diffrent route to
> >reach destination.
> >Its just that the INIT/INIT ACK chunks that communicate the 
> addresses to the
> >peer and if we can send a hostname, we can create the 
> multi-homed association.
> >Only restrition I see is dynamically adding or delteting IP 
> addresses from such
> >an association.
> >
> >And if NAT is sctp aware, which is least likely, you don't 
> even need the
> >hostname as the NAT can itself  translate the addresses in 
> INIT/INIT-ACK.
> >So  we don't require anything new from existing NAT box, all 
> that is required is
> >to send a hostname in the INIT/ INIT ACK that will be resolved to the
> >address(es) of NAT. So probably a new interface that allows 
> a user to specify a
> >hostname for a socket to bind to. If the NAT io
> >
> >regards
> >manish
> >www.hssworld.com
> >
> >
> >
> >
> >
> >[email-masked] on 11/28/2002 06:03:35 PM
> >
> >To:   Manish Rajpal/HSS@HSS, [email-masked]
> >cc:   [email-masked]
> >
> >Subject:  RE: Multihoming with NAT
> >
> >
> >
> >
> >     Hi!
> >
> >  
> >
> >>hi,
> >>
> >>I don't think so, multihoming can work very well behind a NAT
> >>too. if NAT can
> >>translate one address, it can translate n addresses. I don't
> >>    
> >>
> >
> >     I think this is precisely the problem... NATs don't 
> know anything about
> >SCTP, so at most they can translate the source address of 
> the IP packet. All the
> >deployed NATs are not ready to recognize Protocol Number 132 
> and then look
> >inside every of such packets and recognize an INIT/INT ACK 
> chunk, so it can dig
> >inside the packet and recognize de address parameters...
> >
> >     Of course, if you re-code a NAT to do such thing, I 
> think it would work...
> >:-/ But, who is the one that is going to re-code all the 
> existing NATs...?
> >
> >     Besides, I don't really think that having multihoming 
> while being behind a
> >NAT is really anything useful... I'm not an expert, but I 
> would say that you
> >normally have only one NAT that is "covering" a stub domain. 
> It means that all
> >the packets have to go anyway through the NAT... Well, you 
> can always have
> >several netwok cards, and then multihoming would prevent 
> failure if one of the
> >cards itself fails, but it won't prevent about misbehaving 
> routers in the way...
> >
> >  
> >
> >>foresee any issue.
> >>In fact, with NAT, its possible that a host running sctp and
> >>having single
> >>address can appear as a multihomed host to the peer. Only NAT
> >>box has to Map
> >>both the external addresses to a single internal address.
> >>    
> >>
> >
> >     But it has to be able to do so... which is not true so far...
> >
> >     BR Iv
> >
> >-------------------------------------------------------------
> -----------
> >
> >
> >án Arias Rodríguez
> >
> >  
> >
> >>regards
> >>manish
> >>www.hssworld.com
> >>
> >>
> >>
> >>
> >>"Randall Stewart (cisco)" <[email-masked]> on 11/28/2002 01:09:00 AM
> >>
> >>To:   Manish Rajpal/HSS@HSS
> >>cc:   [email-masked]
> >>
> >>Subject:  Re: Multihoming with NAT
> >>
> >>
> >>
> >>
> >>Doing this in the kernel is very very difficult.. (see my
> >>earlier email on
> >>this subject).
> >>
> >>To get by a nat one can always just send a INIT with no addresses...
> >>After all multi-homing behind a NAT is not going to work anyway..
> >>
> >>R
> >>
> >>[email-masked] wrote:
> >>
> >>    
> >>
> >>>Hi
> >>>
> >>>The socket draft - 04 no-where specifies an option for user
> >>>      
> >>>
> >>to provide a
> >>    
> >>
> >>>hostname for an address. This
> >>>creates a problem when a multi-homed endpoint is behind a
> >>>      
> >>>
> >>NAT. As discussed in
> >>    
> >>
> >>>sctp applicabilty
> >>>statement, this requires a hostname to be sent in INIT/INIT ack.
> >>>My question is how to get a hostname for the address
> >>>      
> >>>
> >>provided in sctp-socket
> >>    
> >>
> >>>interface.
> >>>
> >>>regards
> >>>manish
> >>>www.hssworld.com
> >>>
> >>>DISCLAIMER: This message is proprietary to Hughes Software Systems
> >>>Limited (HSS) and is intended solely for the use of the individual
> >>>to whom it is addressed. It may contain  privileged or confidential
> >>>information  and should not be circulated or used for any
> >>>      
> >>>
> >>purpose other
> >>    
> >>
> >>>than for what it is intended. If you have received this
> >>>      
> >>>
> >>message in error,
> >>    
> >>
> >>>please notify the originator immediately. If you are not 
> the intended
> >>>recipient, you are notified that you are strictly prohibited
> >>>      
> >>>
> >>from using,
> >>    
> >>
> >>>copying, altering, or disclosing the contents of this
> >>>      
> >>>
> >>message. HSS accepts
> >>    
> >>
> >>>no responsibility for loss or damage arising from the use of
> >>>      
> >>>
> >>the information
> >>    
> >>
> >>>transmitted by this email including damage from virus.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>--
> >>Randall R. Stewart
> >>ITD
> >>Cisco Systems Inc.
> >>[email-masked] 815-342-5222(cell) or 815-477-2127(office)
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>    
> >>
> >
> >
> >  
> >
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
> 
>

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 02 Dec 2002 16:39:46 -0600

Serkan:

And so why would one what to do this? It seems to me that you
are saying any IP packet headed for IP1' is translated and goes
to IP1 (and of course the same for IP2')...

Why not just assign IP1' to the host?

And even at that.. hostname addresses don't give you any
advantage in this scenario..

R