[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: About draft-thakur-v6oanand.thakur@hpsglobal.comps-3gpp-cases-00.txt



dear juha wiljakka,

on 27th nov,2002 juha wiljakka wrote:

>In Atlanta meeting, draft-wiljakka-3gpp-ipv6-transition-02.txt was approved
>to become a working group document for v6ops wg, and I am planning to 
>publish it as -00 v6ops draft next week. I am proposing that we could use 
>your document as an input document for the v6ops wg doc and mention your 
>names in the acknowledgement section. How would you like that idea? 
>The best way to give input would be commenting our latest draft - work is
>currently being done to update that. Deadline for comments would be Sunday
>01.12.02.

i guess that is the best thing to do. though i find that our basic idea is
the same (logic behind the choice of different transition mechanisms) here
are some general comments on your latest draft:

1) section 3.2 :
i don't think any of the tunneling mechanisms discussed so far is
good/reliable enough. what i suggest is that a NAPT + DNS_ALG like mechanism
be used to create a new ipv4 header and tunnel the original ipv6 packet
inside this header.this mechanism will be valid & efficient when v6 has been
deployed at a small as well as at a large scale unlike some of the other
tunneling mechanisms. also since napt-pt usage is suggested in
(3.4)therefore these translators will be all that is required in either
scenario (3.3 and 3.4). whether tunneling is done or translation is done
with the gathered information will be decided by the edge router depending
on 
whether the final destination is v6(tunneling) or v4(translation).

2)section 3.4 :
i think the suggestion to use multiple translators for load sharing is a
very good idea as it not only does away with the problem of forwarding
delays but also to a certain extent solves the 'single point of failure'
problem. though the multiple translators will have to share address pools
and configuration information. one very important point that i find missing
here is : 
since usage of napt + dns_alg is transparent to the mobile ipv6 node, it
will 'think' that it is communicating with a mobile ipv6 node only and tend
to send it binding updates at regular intervals of time. the destination
being an ipv4 node(mobile or otherwise) will not understand it and drop the
bu packets. so what i suggest is that the BA (binding acknowledge) bit be
always set when a v6 node sends binding updates.if no acknowledgement is
received after a configurable number of attempts(e.g 3), the mobile node
will assume one or more of the following 3 conditions must be true: 
1)destination is a v4 node(mobile or otherwise) 
2)destination is v6 but not mobility enabled or 
3)network congestion 
so,the v6 node will,as a solution to any of the above mentioned cases,
reroute it's packets through it's home agents for the remainder of the
session.

thanks
anand thakur
HCL Perot Systems

p.s : thanks for your comments