RE: draft-thakur-v6ops-3gpp-cases-00.txt comments

["Thakur, Anand" <Anand.Thakur@hpsglobal.com>]

hi,
first of all thanks for your comments.
actually what i have proposed is something very similar to NAT-PT but is not
exactly "translation", but a new tunneling mechanism. the reason for using
the tunneling mechanism is explained in 2.2. as you may have noticed, i have
mentioned that header details (destination address and port number) will be
collected using normal NAT-PT + DNS_ALG  mechanism (as mentioned in rfc
2766)  but this information will not be used to translate the IPV6/IPV4
header but to encapsulate it within another IPV6/IPV4 header.

as far as 2.3 (4) is concerned. the main objective of this sub-section is to
raise a few questions like how a mobile ipv6 node can avoid sending binding
updates to a  ipv4 (which may or may not be mobility enabled) node and a few
other questions as well, which i hope to answer myself in my forthcoming 
(-01) draft.

thanks
anand


> -----Original Message-----
> From:	Jun-ichiro itojun Hagino [SMTP:itojun@iijlab.net]
> Sent:	Sunday, November 17, 2002 11:29 PM
> To:	v6ops@ops.ietf.org
> Subject:	draft-thakur-v6ops-3gpp-cases-00.txt comments
> 
> 	i'm not sure if the way transition mechanisms are presented in 2.3
> 	is the best way to capture multiple translation techniques.
> 	it goes into too much detail in some place (like DNS-ALG behavior),
> 	it does not go into details in some places.
> 
> 2.3 (2)
> 
> >   it itself creates . This "A" response consists of an IP address of
> >   the router itself and a port number that this router will use to 
> >   identify 'B'(similar to NATting). These two responses are eventually
> 
> 	first, we cannot return port number in A DNS RR.   (*)
> 	second, this subsection seems to me a proposal for new transition
> 	mechanism.  if you are just making a recap of some other mechanism,
> 	which mechanism is it? (**)
> 
> 2.3 (3)
> 
> 	ditto for (**).
> 
> 2.3 (4)
> 	
> 	it basically documents behavior of NAT-PT (or some other translation
> 	methodology) in the presense of mobile-ip6, right?  if so, just
> 	say so.
> 
> 2.3 (5)
> 
> 	ditto for (*) and (**).
> 
> itojun