Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 23 Feb 2004 13:20:11 -0000

hi all,

teeny comment:

> > 2) As another feature that could be useful, the node may be 
> > behind a NAT and may want to reserve a public address. 
> > However the node may not yet know the IP address of its 
> > correspondent nodes to send the NSLP request to. E.g. this 
> > could be the case when the node wants to receive incoming 
> > requests (for P2P applications, Web server, etc.). The node 
> > may also be behind a firewall, and  similarly, the node may 
> > want to open the appropriate pinholes in the firewall to 
> > accept incoming requests. So to summarize, it would be useful 
> > if the node could open pinholes in the firewall, and/or make 
> > reservation for a public IP address in a NAT without knowing 
> > the IP address of the data sender (the node may not know it 
> > yet), nor the IP address at the Application Server (there may 
> > not be any Application Server) (section 4.2.1).
> 
> you are right. we should add this to the draft. thanks. 
> 

as an FYI, there is an open issue on how GIMPS should attempt
to handle the NATFW messages that would be needed to make such
requests (for public IP addresses). The question is basically
whether such messages need some 'special' routing (different
from normal on-path routing), or whether they can be handled
correctly by concocting flow identifiers with the right set
of properties. More is in 8.12 of 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-01.txt
(this also addresses some other issues).

comments welcome,

robert h.

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