Re: [v4v6interim] You have been dugg!

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 16 October 2008 08:16 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AAE3A6B2E; Thu, 16 Oct 2008 01:16:28 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8025C3A6B2E for <v4v6interim@core3.amsl.com>; Thu, 16 Oct 2008 01:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599]
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 Ul20CHfsYKkK for <v4v6interim@core3.amsl.com>; Thu, 16 Oct 2008 01:16:25 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 45DC63A6AA9 for <v4v6interim@ietf.org>; Thu, 16 Oct 2008 01:16:25 -0700 (PDT)
Received: from nirrti.it.uc3m.es (nirrti.it.uc3m.es [163.117.139.38]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m9G8GoDk009115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2008 10:16:55 +0200 (CEST) (envelope-from iljitsch@muada.com)
Message-Id: <9FEB64A3-5FD4-43DC-AD55-6D7464737B16@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Fred Baker <fred@cisco.com>
In-Reply-To: <8094EF71-2475-48B5-8F26-F926769CBF91@cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 16 Oct 2008 10:17:03 +0200
References: <732E532B-97C7-465C-BBE0-FD1B442DB21E@muada.com> <7E414550-E1C7-46BB-A7AD-D4F128903046@cisco.com> <290F8ED4-F51C-429F-9DD6-F904996A1CED@muada.com> <8094EF71-2475-48B5-8F26-F926769CBF91@cisco.com>
X-Mailer: Apple Mail (2.929.2)
Cc: v4v6interim@ietf.org
Subject: Re: [v4v6interim] You have been dugg!
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

On 14 okt 2008, at 0:23, Fred Baker wrote:

>> That everything happens mostly automatic and is easy otherwise. For  
>> instance, in IPv4 you have to think about how big each subnet is.  
>> In IPv6 you don't.

> I disagree. The discussion of /48 vs /56 vs /60 vs /64 comes to mind.

Which was a bad idea; one prefix length for everyone is preferable.

But it's also irrelevant to the discussion at hand, what I was talking  
about is that all IPv6 subnets are (should be) /64, while with IPv4  
you need to think about how many hosts will have to fit in a subnet  
and size it accordingly.

> we have a way to assign a prefix using DHCP. You're telling me it  
> doesn't know the prefix length? If so, it's broken. I haven't read  
> that spec; remind me which it is?

Are you saying that you want to use DHCPv6 prefix delegation to give  
out prefixes to IPv6 hosts that are reachable from the IPv4 side  
through IVI? Not sure if that makes everything easier. One of the  
issues with PD is to get the routers to know what's going on, and the  
host would still have to fill in the correct lower bits.

With DHCPv6 address assignment you just get the address, with no  
knowledge about the subnet. For the host this is probably not a big  
deal (in the IVI case with presumably no other hosts on the same  
subnet) but the routers need to know the subnet so they know how to  
send packets to the host in question.

>> The situation where a static mapping is set up means that the  
>> configuration can be limited to the translation box, this simply  
>> makes much more sense on every level.

> Actually, not so.

How does it make sense to have to touch more boxes?

Or, what benefit is there that outweighs this downside?

> And this differs from NAT64, which you spoke positively about, in  
> what way?

NAT64 doesn't impose addressing requirements on the IPv6 side.
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim