Subject: RE: [Mipshop] Re: NAT Traversal for GIST (was GIST 802.21)

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 7 Aug 2006 10:56:09 +0100

hi,

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> 
> Hi Robert,
> 
> On Thu, Aug 03, 2006 at 10:03:55PM +0100, Robert Hancock wrote:
> 
> (snip)
> 
> >
> > However
> > =======
> >
> > before directly looking at these, there is a more fundamental
question
> > about the MIH signalling requirements - namely, will the signalling
> > messages carry addressing payloads (IP addresses of neighbour ARs
> > for example, or of the MN). the right way to handle NAT traversal
> > for the signalling depends critically on the answer to that. there
> > is a little more discussion of that point in section 3.5 of the
> > design considerations draft
> > (draft-hepworth-mipshop-mih-design-considerations-00).
> 
> There is a proposal in 802.21 WG that defines an Information Element
> for carrying DHCP server address and Foreign Agent or Access Router
> address.  Do you think this makes NAT traversal difficult?

in general, i think the answer to that question depends on the relative
positions in the network topology of all of:
- the terminal
- the MIH server
- the 'other' server (DCHP, MIP FA, whatever), and
- the NAT itself, including where its internal and external sides are

it's easy to see that there are potentially an awful lot of scenarios
here;
that, as much as anything else, is what makes the NAT traversal problem
hard even to state, let alone analyse.

for the DHCP example you raise, one can imagine covering a large
proportion
of the scenarios by saying that server addressing information has to
be expressed in terms of the address space seen by the terminal. in 
that case it just becomes a configuration problem on the MIH server
to work out what addresses to report, but one requires no specific new
NAT functionality to translate the payloads (you don't expect the DHCP
protocol itself to run through the NAT). obviously, that has to be
written very explicitly in the protocol specification.

however, it needs to be borne in mind that carrying out the
configuration 
might be a challenge (consider a case where the NAT was at 
the boundary of a moving network for example). there might be hard
to diagnose error cases where the .21 messages returned one type of
information, and the 'native' discovery mechanism (e.g. for DHCP
servers) returned something else. however, i think this is then a
different question from the transport protocol design.

cheers,

robert h.

> Yoshihiro Ohba

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop