[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-thakur-v6ops-3gpp-cases-00.txt comments
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