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/_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
