Re: [Softwires] FW: New Version Notification for draft-lee-softwire-6rd-udp-01

[prashant kapoor <[e-mail]>]

Timothy Wrote



>, Yiu wrote about draft-lee-softwire-6rd-udp-01:



> 1. How to discover 6rd parameters? ISP relies on radius can pass the

> parameters over the existing infrastructure. However, ISP relies on dhcp

> may require some OOB discovery procedure.

>See my draft:

>http://www.ietf.org/id/draft-baldwin-dhc-softwire-anycast-dhcp-00.txt



Certainly will go through this and come back.



>

> 2. Since the 6rd udp host is behind NAT, so it won't know the NAT-ed udp

> port after NAT-ing. We solve this problem by asking the 6rd BR to fill in

> the port information. However, this design virtually creates a NAT66

> scenario.



>The BR should inform the host what port number is being used.



 This could be  also mean interfering with  the OS stack to

 assign port numbers or how is already assigned port number changed and its implications on the application?







>A potential problem is that it uses a lot of address space, a /48 per IPv4

>address. It also lacks the direct peer to peer communication that is

>possible using 6RD, 6to4 and Teredo.

>Would the server model be popular enough to justify the use of large

>amounts of address space? Could not DHCPv6 be used to allocate address to

>the hosts?

>Two alternative approaches, use a well known destination port combined port-

>forwarding configured using UPnP, NAT-PMP or manually. This has the same

>address efficiency as classical 6RD.

>Or use a /64 prefix like Teredo, using 48 bits for the IPv4 address and

>port, leaving 14 bits to address local hosts, but I expect such use to be

>uncommon. There would need to be a protocol to find a shorter route perhaps

>transversing NATs, behind the same NAT, or perhaps native on the same link.

>The border router remains stateless.





This approach has been essentially adopted in order to achieve 6rd behind hgw  Ipv4 Nat where

controlling the gateway/NAT  is not desirable due to any possible reason while  keeping

the 6rd BR operation stateless and at same time catering for a non complex and shorter

development  lifecyle.





Using udp as the transport protocol which is standard socket operations in all

host operating systems,doesn't interfere with the Nat operation at all in the hgw , requires simpler

modifications in already developed 6rd Br solutions from a software prospective.



The other consideration was to avoid any heavier middle layer transport  in order to keep things lightweight.



The /48 and  is a shortcoming of this approach and the answer is classic 6rd itself, considering that this is only a transitional technology and is relevant until the control of hgw is achievable.







Prashant at Xavient















 		 	   		  
_________________________________________________________________
Catch the latest in the world of fashion
http://lifestyle.in.msn.com/