Discussion :
following thoughts on the issue of burning too much space per host in 6rd udp
Since the maximum delegated prefix length is /48 ,if providing such a prefix
length for each 6rd host is not affordable
an alternate method is also advised . In this model the delegated
prefix length can be upto /64 as per classic 6rd solution ,the ipv6 prefix to
be allocated to host is not calculated by
the auto-config mechanism of the host but by the 6rd udp client itself.
The 65th to 80th bit of the Ipv6 prefix are intentionally kept zero padded in
order for the BR to include the source port
information,also the mac address of the host is used for last 48 bits of Ipv6
address in order to provide a unique
Ipv6 address.
This ensures the use of /64 length 6rd delegated prefix per host eliminating
the large address space wasted per host issue as well
as complete stateless operation of BR
Inspired from draft-carpenter-softwire-sample-00.txt :-)
From: [email protected]
To: [email protected]
Subject: RE: [Softwires] FW: New Version Notification for
draft-lee-softwire-6rd-udp-01
Date: Tue, 1 Jun 2010 12:27:18 +0000
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
All the post budget analysis and implications Sign up now.
_________________________________________________________________
Bollywood, beauties and the latest flicks on MSN entertainment
http://entertainment.in.msn.com/_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
