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

prashant kapoor <parry26@hotmail.com> Thu, 10 June 2010 21:55 UTC

Return-Path: <parry26@hotmail.com>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0313A65A6 for <softwires@core3.amsl.com>; Thu, 10 Jun 2010 14:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level:
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwS4LJNemzUb for <softwires@core3.amsl.com>; Thu, 10 Jun 2010 14:55:39 -0700 (PDT)
Received: from bay0-omc4-s21.bay0.hotmail.com (bay0-omc4-s21.bay0.hotmail.com [65.54.190.223]) by core3.amsl.com (Postfix) with ESMTP id 109B73A63C9 for <softwires@ietf.org>; Thu, 10 Jun 2010 14:55:39 -0700 (PDT)
Received: from BAY120-W29 ([65.54.190.199]) by bay0-omc4-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 14:55:41 -0700
Message-ID: <BAY120-W2908A9D0DB43D961710F5BA3D80@phx.gbl>
Content-Type: multipart/alternative; boundary="_c4d6554f-a728-41a3-b429-bdb0726813fc_"
X-Originating-IP: [208.252.133.131]
From: prashant kapoor <parry26@hotmail.com>
To: softwires@ietf.org
Date: Thu, 10 Jun 2010 21:55:40 +0000
Importance: Normal
In-Reply-To: <D59898AE54D95941BCB81E315F29D87C05BC6FBE@Xav-Mail.xavient.com>
References: <C829A56E.2406C%yiu_lee@cable.comcast.com>, <D59898AE54D95941BCB81E315F29D87C05BC6FB7@Xav-Mail.xavient.com>, <D59898AE54D95941BCB81E315F29D87C05BC6FB8@Xav-Mail.xavient.com>, <D59898AE54D95941BCB81E315F29D87C05BC6FB9@Xav-Mail.xavient.com>, <D59898AE54D95941BCB81E315F29D87C05BC6FBE@Xav-Mail.xavient.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Jun 2010 21:55:41.0731 (UTC) FILETIME=[AB763730:01CB08E7]
Subject: Re: [Softwires] FW: New Version Notification for draft-lee-softwire-6rd-udp-01
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jun 2010 21:55:41 -0000


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: parry26@hotmail.com
To: softwires@ietf.org
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/