From owner-v6ops@ops.ietf.org  Wed Jun  4 02:41:14 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1E5EF3A696F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed,  4 Jun 2008 02:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 pGKN4L0yrj3I
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed,  4 Jun 2008 02:41:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 16F903A6C69
	for <v6ops-archive@lists.ietf.org>; Wed,  4 Jun 2008 02:41:10 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K3pJr-000AAw-S7
	for v6ops-data@psg.com; Wed, 04 Jun 2008 09:30:11 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <root@core3.amsl.com>)
	id 1K3pJn-000A8k-E1
	for v6ops@ops.ietf.org; Wed, 04 Jun 2008 09:30:10 +0000
Received: by core3.amsl.com (Postfix, from userid 0)
	id 22F2B3A6C53; Wed,  4 Jun 2008 02:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
Subject: I-D Action:draft-ietf-v6ops-addcon-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080604093002.22F2B3A6C53@core3.amsl.com>
Date: Wed,  4 Jun 2008 02:30:02 -0700 (PDT)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.


	Title           : IPv6 Unicast Address Assignment Considerations
	Author(s)       : G. Van de Velde, et al.
	Filename        : draft-ietf-v6ops-addcon-08.txt
	Pages           : 34
	Date            : 2008-06-04

One fundamental aspect of any IP communications infrastructure is its
addressing plan.  With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches
to network addressing.  Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of
IPv6.  This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6
deployments.  The document also provides IPv6 addressing case studies
for both an enterprise and an ISP network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-addcon-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-06-04022248.I-D@ietf.org>

--NextPart--



From v6nihm3ftizehxupylw0xbrlj5eipc@ptw.com  Wed Jun  4 04:08:43 2008
Return-Path: <v6nihm3ftizehxupylw0xbrlj5eipc@ptw.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 107E23A6B12
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed,  4 Jun 2008 04:08:43 -0700 (PDT)
X-Quarantine-ID: <Gu61t81lkrWz>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA
	\256 Official Site [...]
X-Spam-Flag: NO
X-Spam-Score: -17.426
X-Spam-Level: 
X-Spam-Status: No, score=-17.426 tagged_above=-999 required=5
	tests=[BAYES_60=1, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95,
	HTML_IMAGE_ONLY_12=2.46, HTML_IMAGE_RATIO_04=0.172,
	HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MANGLED_OFF=2.3,
	MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457,
	RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5,
	RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5,
	RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643,
	RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666,
	SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10,
	URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100]
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 Gu61t81lkrWz
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed,  4 Jun 2008 04:08:42 -0700 (PDT)
Received: from sp2.brzesko.edu.pl (sp2.brzesko.edu.pl [83.15.5.34])
	by core3.amsl.com (Postfix) with SMTP id 932F43A6AD2
	for <v6ops-archive@lists.ietf.org>; Wed,  4 Jun 2008 04:08:41 -0700 (PDT)
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Message-Id: <20080604-40848.6681.qmail@sp2.brzesko.edu.pl>
To: <v6ops-archive@lists.ietf.org>
Subject: Dear v6ops-archive@lists.ietf.org 84% 0FF
From: VIAGRA ® Official Site <v6ops-archive@lists.ietf.org>
MIME-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Date: Wed,  4 Jun 2008 04:08:41 -0700 (PDT)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>
        <html>
<body>
<img src="http://www.foantex.com" width=0 height=0>
<table cellpadding=0 cellspacing=0 width=600 align=center>
	<tr>
		<td class=EC_container bgcolor="#F2F2F2">
			<table cellpadding=0 cellspacing=0 width="100%">
				<tr>
					<td>
                                                                                        
                                                <div align=center> <a href="http://www.cosatte.com" target="_blank"><img src="http://www.duanter.com/3.gif" border=0 alt="Click Here!"></a> </div>
					                    </td>
				</tr>
				<tr>
					<td class=EC_legal>
		<br>

                		©2007 Microsoft | <a href="http://www.quenttri.com" target="_blank">Unsubscribe</a> | <a href="http://www.baicken.com" target="_blank">More Newsletters</a> | <a href="http://www.baicken.com" target="_blank">Privacy</a><br><br>
		Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

                
		</td>
	</tr>
</table>



        </div>
    </div>

          </div>
    
    </body>
</html>



From owner-v6ops@ops.ietf.org  Thu Jun  5 01:00:35 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BB0773A68E0
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 01:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.52
X-Spam-Level: 
X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=-1.025,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 jlf45iLrlSOF
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 01:00:31 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id F1C8A3A6BBF
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 01:00:30 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4AGo-000CLs-HH
	for v6ops-data@psg.com; Thu, 05 Jun 2008 07:52:26 +0000
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.69 (FreeBSD))
	(envelope-from <gvandeve@cisco.com>)
	id 1K4AGk-000CL1-6r
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 07:52:23 +0000
X-IronPort-AV: E=Sophos;i="4.27,593,1204498800"; 
   d="scan'208";a="10823711"
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
  by ams-iport-1.cisco.com with ESMTP; 05 Jun 2008 09:51:51 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m557ppSV001437
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 09:51:51 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87])
	by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m557pp5l009052
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 07:51:51 GMT
Received: from xmb-ams-33c.emea.cisco.com ([144.254.231.91]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 5 Jun 2008 09:51:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: FW: DISCUSS: draft-ietf-v6ops-addcon 
Date: Thu, 5 Jun 2008 09:50:42 +0200
Message-ID: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: DISCUSS: draft-ietf-v6ops-addcon 
Thread-Index: Aci8EWg13T4769rKR6e1RrQoNG6xeQKGOgBgACrNn5AAAq6zIA==
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 05 Jun 2008 07:51:30.0320 (UTC) FILETIME=[F7400100:01C8C6E0]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2601; t=1212652311; x=1213516311;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gvandeve@cisco.com;
	z=From:=20=22Gunter=20Van=20de=20Velde=20(gvandeve)=22=20<gv
	andeve@cisco.com>
	|Subject:=20FW=3A=20DISCUSS=3A=20draft-ietf-v6ops-addcon=20
	|Sender:=20;
	bh=pvBSam8NegRSmw5bikmS9zTA4mRI5jqd3+FdliqI3Fg=;
	b=HkFBSxADMRjZQMXyFD/K3ENacRh3ltfvsV6WhWbnwFhNhwovaNLYBhmmlY
	1dU4TNprpYp9JQPfBe7Z+WfHBAp77rzh8m6VA9izZW1bT61x/Z/PlGzqyB60
	2ClrQVypLW;
Authentication-Results: ams-dkim-2; header.From=gvandeve@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim2001 verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi All,

During IESG review an interresting comment appeared regarding=20
different then /64 addresses and would like to understand if the WG has
some opinion before 'removing' section 3.1 and 3.3.

See context of the Comment below.

Brgds,
G/

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20
Sent: Thursday, June 05, 2008 8:53 AM
To: Gunter Van de Velde (gvandeve); iesg@ietf.org
Cc: v6ops-chairs@tools.ietf.org; draft-ietf-v6ops-addcon@tools.ietf.org
Subject: RE: DISCUSS: draft-ietf-v6ops-addcon=20

Hi Gunter,=20

> GV> Maybe an extra sentence should be added here to make this crystal=20
> GV> clear? What about the following:
>=20
> GV> CHANGED TO:
> GV> Based on RFC4291 it is legal for any IPv6 unicast address starting

> GV> with binary address '000' to have a subnet prefix larger than,=20
> GV> smaller than or equal to 64 bits. Each of these three options is=20
> GV> discussed in this document. This document mainly considers global=20
> GV> addresses (assigned from RIR/LIR) and ULAs and while neither of=20
> GV> these address types start with binary "000"
> GV> only /64 prefixes are allowed on these types of addresses.
>=20
> GV> Is the above an acceptable solution?=20

If Sections 3.1 and 3.3 do not apply to global addresses or ULAs, what
addresses they do apply to?

(In particular, the discussion doesn't seem relevant for IPv4-Compatible
or IPv4-Mapped Addresses, and clearly isn't about the Unspecified or the
Loopback Address. And this kind of detailed advice doesn't seem
appropriate for some future, not-yet-defined addresses, whose properties
we don't really know yet.)

If the intent is simply to describe how to use prefixes other than
/64 with global addresses -- which I know some folks are doing -- then
this document needs have "Updates: RFC 4291" on cover page, and be
explicit about changing the "MUST" in RFC 4291. (And obviously, there
needs to be rough IETF consensus to make this change.)

> Section 6 should say that using subnet prefixes other than /64 breaks=20
> security mechanisms such as Cryptographically Generated Addresses=20
> (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible=20
> to use protocols that depend on them.
>=20
> GV> It is indicated in Section 3. that these mechanisms are broken.=20

The text that was added to Section 3 does not mention CGAs or HBAs.
Also, it should be in Section 6, as the current text there ("This
document doesn't add any new security considerations...") is incorrect.

Best regards,
Pasi



From owner-v6ops@ops.ietf.org  Thu Jun  5 09:19:39 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 714383A6B1D
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 09:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5
	tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
	HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 Z94hI0vw9NxS
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 09:19:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 659963A69AC
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 09:19:38 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4I3e-000BPD-7P
	for v6ops-data@psg.com; Thu, 05 Jun 2008 16:11:22 +0000
Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jdunn@mitre.org>)
	id 1K4I3U-000BNb-4k
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 16:11:17 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55GBBcI002073
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 12:11:11 -0400
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55GBBYa002054
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 12:11:11 -0400
Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 5 Jun 2008 12:11:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8C726.B84C25A3"
Subject: Use of extended prefix lengths
Date: Thu, 5 Jun 2008 12:10:44 -0400
Message-ID: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Use of extended prefix lengths
Thread-Index: AcjHJrVrnvQP0ohYRlKXFjLwwBbEYQ==
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: <v6ops@ops.ietf.org>
Cc: "Dunn, Jeffrey H." <jdunn@mitre.org>
X-OriginalArrivalTime: 05 Jun 2008 16:11:10.0252 (UTC) FILETIME=[C4AE96C0:01C8C726]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8C726.B84C25A3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Colleagues,

=20

I was discussing the possibility of using IPv6 prefix lengths greater
than 64 bits with some colleagues and wondered if anyone had any
experience with doing so.  Specifically, has anyone tried it?
Thoughts?

=20

Best Regards,=20
 =20
Jeffrey Dunn=20
Info Systems Eng., Lead=20
 =20
Center for Enterprise Modernization=20
MITRE Corp.=20
 =20
301-429-5377 (Office)=20
301-731-8862  (FAX)=20


------_=_NextPart_001_01C8C726.B84C25A3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Times New Roman","serif";
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Colleagues,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I was discussing the possibility of using IPv6 =
prefix
lengths greater than 64 bits with some colleagues and wondered if anyone =
had
any experience with doing so.&nbsp; Specifically, has anyone tried =
it?&nbsp;
Thoughts?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Best Regards, <br>
&nbsp; <br>
Jeffrey Dunn <br>
Info Systems Eng., Lead <br>
&nbsp; <br>
Center for Enterprise Modernization <br>
MITRE Corp. <br>
&nbsp; <br>
301-429-5377 (Office) <br>
301-731-8862&nbsp; (FAX) <o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C8C726.B84C25A3--



From owner-v6ops@ops.ietf.org  Thu Jun  5 10:19:53 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0398B3A6800
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 10:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.495
X-Spam-Level: 
X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 bOoA9z28GhHw
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 10:19:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 15E9F3A6A9A
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 10:19:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4J3w-000LRN-7Z
	for v6ops-data@psg.com; Thu, 05 Jun 2008 17:15:44 +0000
Received: from [198.32.6.68] (helo=vacation.karoshi.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <bmanning@karoshi.com>)
	id 1K4J3l-000LQ2-CN
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 17:15:38 +0000
Received: from karoshi.com (localhost.localdomain [127.0.0.1])
	by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m55HERp4008412;
	Thu, 5 Jun 2008 17:14:27 GMT
Received: (from bmanning@localhost)
	by karoshi.com (8.12.8/8.12.8/Submit) id m55HER7i008411;
	Thu, 5 Jun 2008 17:14:27 GMT
Date: Thu, 5 Jun 2008 17:14:27 +0000
From: bmanning@vacation.karoshi.com
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
Cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
Message-ID: <20080605171427.GA8269@vacation.karoshi.com.>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
User-Agent: Mutt/1.4.1i
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

 you mean longer than /64? 
 I have built a network out of a /96, using /120's for subnets.
 you have to turn -off- all the autoconfig crap - but it is doable.
 dhcpv6 would have been a real help then.

--bill


On Thu, Jun 05, 2008 at 12:10:44PM -0400, Dunn, Jeffrey H. wrote:
> Colleagues,
> 
>  
> 
> I was discussing the possibility of using IPv6 prefix lengths greater
> than 64 bits with some colleagues and wondered if anyone had any
> experience with doing so.  Specifically, has anyone tried it?
> Thoughts?
> 
>  
> 
> Best Regards, 
>   
> Jeffrey Dunn 
> Info Systems Eng., Lead 
>   
> Center for Enterprise Modernization 
> MITRE Corp. 
>   
> 301-429-5377 (Office) 
> 301-731-8862  (FAX) 
> 



From owner-v6ops@ops.ietf.org  Thu Jun  5 10:27:06 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5D7AB3A6898
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 10:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 WyjE4U4eKMIr
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 10:27:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 790093A697D
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 10:27:05 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4JEA-000NMA-VQ
	for v6ops-data@psg.com; Thu, 05 Jun 2008 17:26:18 +0000
Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <mohacsi@niif.hu>)
	id 1K4JE3-000NJu-4l
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 17:26:16 +0000
Received: from localhost (localhost [IPv6:::1])
	by mail.ki.iif.hu (Postfix) with ESMTP id C65EB84953;
	Thu,  5 Jun 2008 19:26:08 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu
Received: from mail.ki.iif.hu ([127.0.0.1])
	by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id WuaUNcNSRb6c; Thu,  5 Jun 2008 19:26:00 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002)
	id 96924848D6; Thu,  5 Jun 2008 19:26:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by mail.ki.iif.hu (Postfix) with ESMTP id 5BBA584845;
	Thu,  5 Jun 2008 19:26:00 +0200 (CEST)
Date: Thu, 5 Jun 2008 19:26:00 +0200 (CEST)
From: Mohacsi Janos <mohacsi@niif.hu>
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
In-Reply-To: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
Message-ID: <20080605192034.H99897@mignon.ki.iif.hu>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>




On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:

> Colleagues,
>
>
>
> I was discussing the possibility of using IPv6 prefix lengths greater
> than 64 bits with some colleagues and wondered if anyone had any
> experience with doing so.  Specifically, has anyone tried it?
> Thoughts?

One of my colleague tried /126 with DHCPv6 address assignment and it seems 
to be mediocre success:
Linux (Dibbler) client was working almost alright - with some extension
Windows Vista failed  - not really supporting longer prefix.


for point-to-point links prefix longer than /64 was worked without any 
problem on Cisco boxes.

Best Regards,


Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882




>
>
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
>
> Center for Enterprise Modernization
> MITRE Corp.
>
> 301-429-5377 (Office)
> 301-731-8862  (FAX)
>
>



From owner-v6ops@ops.ietf.org  Thu Jun  5 10:35:42 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C170428C156
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 10:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level: 
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.930,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 UJslcEjB0i8h
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 10:35:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id D1E0B28C10F
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 10:35:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4JMA-000On9-R6
	for v6ops-data@psg.com; Thu, 05 Jun 2008 17:34:34 +0000
Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jdunn@mitre.org>)
	id 1K4JM3-000OlY-C6
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 17:34:29 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55HYQog001458
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 13:34:26 -0400
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55HYQDs001451;
	Thu, 5 Jun 2008 13:34:26 -0400
Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 5 Jun 2008 13:34:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Use of extended prefix lengths
Date: Thu, 5 Jun 2008 13:34:21 -0400
Message-ID: <0AC4B700F00DBB4C94F95727E09914140116FD0B@IMCSRV7.MITRE.ORG>
In-Reply-To: <20080605171427.GA8269@vacation.karoshi.com.>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Use of extended prefix lengths
Thread-Index: AcjHL6Bi4Ia+pJV2S06A7j5M1qDJnQAAHM1Q
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605171427.GA8269@vacation.karoshi.com.>
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: <bmanning@vacation.karoshi.com>
Cc: <v6ops@ops.ietf.org>, "Dunn, Jeffrey H." <jdunn@mitre.org>
X-OriginalArrivalTime: 05 Jun 2008 17:34:26.0562 (UTC) FILETIME=[66B6FE20:01C8C732]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Bill,

Interesting.  I noted that prefixes longer than 64 are not prohibited
by the BGP, OSPF or DHCP RFCs, so I got to thinking (I know, very
dangerous).  I am checking with some folks to see if currently
available DHCPv6 server implementation will associate a prefix longer
than 64 bits with a link or link address.  I will keep the list
informed.

Best Regards,
=20
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: bmanning@vacation.karoshi.com
[mailto:bmanning@vacation.karoshi.com]=20
Sent: Thursday, June 05, 2008 1:14 PM
To: Dunn, Jeffrey H.
Cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths

 you mean longer than /64?=20
 I have built a network out of a /96, using /120's for subnets.
 you have to turn -off- all the autoconfig crap - but it is doable.
 dhcpv6 would have been a real help then.

--bill


On Thu, Jun 05, 2008 at 12:10:44PM -0400, Dunn, Jeffrey H. wrote:
> Colleagues,
>=20
> =20
>=20
> I was discussing the possibility of using IPv6 prefix lengths greater
> than 64 bits with some colleagues and wondered if anyone had any
> experience with doing so.  Specifically, has anyone tried it?
> Thoughts?
>=20
> =20
>=20
> Best Regards,=20
>  =20
> Jeffrey Dunn=20
> Info Systems Eng., Lead=20
>  =20
> Center for Enterprise Modernization=20
> MITRE Corp.=20
>  =20
> 301-429-5377 (Office)=20
> 301-731-8862  (FAX)=20
>=20



From owner-v6ops@ops.ietf.org  Thu Jun  5 10:36:58 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0BC4228C10F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 10:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.972
X-Spam-Level: 
X-Spam-Status: No, score=-3.972 tagged_above=-999 required=5 tests=[AWL=0.465,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 6sXjFghtcwlD
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 10:36:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id CC75D3A6BF9
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 10:36:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4JO4-000PAJ-GK
	for v6ops-data@psg.com; Thu, 05 Jun 2008 17:36:32 +0000
Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jdunn@mitre.org>)
	id 1K4JO1-000P9T-6W
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 17:36:30 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55HaSBa007361
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 13:36:28 -0400
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55HaSUl007358;
	Thu, 5 Jun 2008 13:36:28 -0400
Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 5 Jun 2008 13:36:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Use of extended prefix lengths
Date: Thu, 5 Jun 2008 13:35:53 -0400
Message-ID: <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG>
In-Reply-To: <20080605192034.H99897@mignon.ki.iif.hu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Use of extended prefix lengths
Thread-Index: AcjHMUGHzoUy0VSzTIuWCloPjY0ifwAAVApA
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu>
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: "Mohacsi Janos" <mohacsi@niif.hu>
Cc: <v6ops@ops.ietf.org>, "Dunn, Jeffrey H." <jdunn@mitre.org>
X-OriginalArrivalTime: 05 Jun 2008 17:36:28.0435 (UTC) FILETIME=[AF5B5630:01C8C732]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Janos,

Which server did he use?

Best Regards,
=20
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: Mohacsi Janos [mailto:mohacsi@niif.hu]=20
Sent: Thursday, June 05, 2008 1:26 PM
To: Dunn, Jeffrey H.
Cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths




On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:

> Colleagues,
>
>
>
> I was discussing the possibility of using IPv6 prefix lengths greater
> than 64 bits with some colleagues and wondered if anyone had any
> experience with doing so.  Specifically, has anyone tried it?
> Thoughts?

One of my colleague tried /126 with DHCPv6 address assignment and it
seems=20
to be mediocre success:
Linux (Dibbler) client was working almost alright - with some extension
Windows Vista failed  - not really supporting longer prefix.


for point-to-point links prefix longer than /64 was worked without any=20
problem on Cisco boxes.

Best Regards,


Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and
Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882




>
>
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
>
> Center for Enterprise Modernization
> MITRE Corp.
>
> 301-429-5377 (Office)
> 301-731-8862  (FAX)
>
>



From owner-v6ops@ops.ietf.org  Thu Jun  5 10:44:56 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D8DA228C156
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 10:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level: 
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_LOW=-1,
	RDNS_NONE=0.1]
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 iGlD5KtlNOSt
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 10:44:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id E35A228C241
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 10:44:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4JUt-0000Z2-F5
	for v6ops-data@psg.com; Thu, 05 Jun 2008 17:43:35 +0000
Received: from [130.215.36.91] (helo=mail1.wpi.edu)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <cra@WPI.EDU>)
	id 1K4JUp-0000YI-HG
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 17:43:33 +0000
Received: from mcafee.wpi.edu (MCAFEE.WPI.EDU [130.215.36.86])
	by mail1.wpi.edu (8.14.3.Gamma0/8.14.3.Gamma0) with SMTP id m55HhVnw032114
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 13:43:31 -0400
Received: from (130.215.36.186) by mcafee.wpi.edu via smtp
	 id 77dd_e978513c_3326_11dd_9194_0013725b2d50;
	Thu, 05 Jun 2008 14:43:30 -0300
Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21])
	by SMTP.WPI.EDU (8.13.8/8.13.8) with ESMTP id m55HhU3Z000970
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 13:43:30 -0400
	(envelope-from cra@WPI.EDU)
Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1])
	by angus.ind.WPI.EDU (8.14.1/8.13.8) with ESMTP id m55HhUrD021209
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 13:43:30 -0400
Received: (from cra@localhost)
	by angus.ind.WPI.EDU (8.14.1/8.14.1/Submit) id m55HhU1s021208
	for v6ops@ops.ietf.org; Thu, 5 Jun 2008 13:43:30 -0400
X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f
Date: Thu, 5 Jun 2008 13:43:30 -0400
From: Chuck Anderson <cra@WPI.EDU>
To: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
Message-ID: <20080605174330.GB10754@angus.ind.WPI.EDU>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Thu, Jun 05, 2008 at 12:10:44PM -0400, Dunn, Jeffrey H. wrote:
> I was discussing the possibility of using IPv6 prefix lengths greater
> than 64 bits with some colleagues and wondered if anyone had any
> experience with doing so.  Specifically, has anyone tried it?
> Thoughts?

We are using /120's for router links on Ethernet VLANs, and /128 
router loopback addresses without problems.



From owner-v6ops@ops.ietf.org  Thu Jun  5 11:01:23 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2EF8E3A6C32
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 11:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.127
X-Spam-Level: 
X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[AWL=0.310,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 vzT18TMt+uUd
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 11:01:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 8E30E28C0E5
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 11:01:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4Jki-00044G-7l
	for v6ops-data@psg.com; Thu, 05 Jun 2008 17:59:56 +0000
Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jdunn@mitre.org>)
	id 1K4Jkb-00042k-2d
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 17:59:53 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55HxmqQ010720
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 13:59:48 -0400
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m55HxmL0010716;
	Thu, 5 Jun 2008 13:59:48 -0400
Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 5 Jun 2008 13:59:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Use of extended prefix lengths
Date: Thu, 5 Jun 2008 13:58:48 -0400
Message-ID: <0AC4B700F00DBB4C94F95727E09914140116FD19@IMCSRV7.MITRE.ORG>
In-Reply-To: <20080605174330.GB10754@angus.ind.WPI.EDU>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Use of extended prefix lengths
Thread-Index: AcjHNafRV49kqdbEQiqbPg5+p4q/MQAABzUw
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605174330.GB10754@angus.ind.WPI.EDU>
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: "Chuck Anderson" <cra@WPI.EDU>, <v6ops@ops.ietf.org>
Cc: "Dunn, Jeffrey H." <jdunn@mitre.org>
X-OriginalArrivalTime: 05 Jun 2008 17:59:48.0319 (UTC) FILETIME=[F1C0AEF0:01C8C735]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Cool.  What E-switch are you using?

Best Regards,
=20
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Chuck Anderson
Sent: Thursday, June 05, 2008 1:44 PM
To: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths

On Thu, Jun 05, 2008 at 12:10:44PM -0400, Dunn, Jeffrey H. wrote:
> I was discussing the possibility of using IPv6 prefix lengths greater
> than 64 bits with some colleagues and wondered if anyone had any
> experience with doing so.  Specifically, has anyone tried it?
> Thoughts?

We are using /120's for router links on Ethernet VLANs, and /128=20
router loopback addresses without problems.




From owner-v6ops@ops.ietf.org  Thu Jun  5 11:05:51 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C0B6028C0E5
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 11:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,
	RDNS_NONE=0.1]
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 8CC2dosN+gQK
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 11:05:48 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C43053A6CC9
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 11:05:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4Jpy-000590-En
	for v6ops-data@psg.com; Thu, 05 Jun 2008 18:05:22 +0000
Received: from [66.117.32.22] (helo=srv013.carpathiahost.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <kloch@kl.net>)
	id 1K4Jpv-00058L-KF
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 18:05:20 +0000
Received: from [66.117.52.141] (unknown [66.117.52.141])
	by srv013.carpathiahost.net (Postfix) with ESMTP id 2376C937CA
	for <v6ops@ops.ietf.org>; Thu,  5 Jun 2008 14:05:19 -0400 (EDT)
Message-ID: <48482AD3.4040509@kl.net>
Date: Thu, 05 Jun 2008 14:05:07 -0400
From: Kevin Loch <kloch@kl.net>
User-Agent: Thunderbird 2.0.0.9 (X11/20071211)
MIME-Version: 1.0
To: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu>
In-Reply-To: <20080605192034.H99897@mignon.ki.iif.hu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Mohacsi Janos wrote:

> for point-to-point links prefix longer than /64 was worked without any 
> problem on Cisco boxes.
> 

/112 is commonly used on router links and works fine.  I have also used
it on server subnets with various *BSD/linux/Solaris in it works there
also.

- Kevin



From owner-v6ops@ops.ietf.org  Thu Jun  5 11:32:04 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D0C723A69F9
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 11:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Mh1+ohBNzURK
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 11:32:01 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id CC7BF3A68D3
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 11:32:00 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4KCJ-0009fS-CW
	for v6ops-data@psg.com; Thu, 05 Jun 2008 18:28:27 +0000
Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <mohacsi@niif.hu>)
	id 1K4KCD-0009bH-41
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 18:28:25 +0000
Received: from localhost (localhost [IPv6:::1])
	by mail.ki.iif.hu (Postfix) with ESMTP id 155A0848D6;
	Thu,  5 Jun 2008 20:28:18 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu
Received: from mail.ki.iif.hu ([127.0.0.1])
	by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Hcu6KPNVZt+y; Thu,  5 Jun 2008 20:28:15 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002)
	id A39B584888; Thu,  5 Jun 2008 20:28:15 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by mail.ki.iif.hu (Postfix) with ESMTP id A254484675;
	Thu,  5 Jun 2008 20:28:15 +0200 (CEST)
Date: Thu, 5 Jun 2008 20:28:15 +0200 (CEST)
From: Mohacsi Janos <mohacsi@niif.hu>
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
cc: v6ops@ops.ietf.org
Subject: RE: Use of extended prefix lengths
In-Reply-To: <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG>
Message-ID: <20080605202737.F99897@mignon.ki.iif.hu>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
 <20080605192034.H99897@mignon.ki.iif.hu> <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>




On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:

> Janos,
>
> Which server did he use?

We tried dibbler dhcpv6 server.
  	Regards,
  		Janos Mohacsi

>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> -----Original Message-----
> From: Mohacsi Janos [mailto:mohacsi@niif.hu]
> Sent: Thursday, June 05, 2008 1:26 PM
> To: Dunn, Jeffrey H.
> Cc: v6ops@ops.ietf.org
> Subject: Re: Use of extended prefix lengths
>
>
>
>
> On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:
>
>> Colleagues,
>>
>>
>>
>> I was discussing the possibility of using IPv6 prefix lengths greater
>> than 64 bits with some colleagues and wondered if anyone had any
>> experience with doing so.  Specifically, has anyone tried it?
>> Thoughts?
>
> One of my colleague tried /126 with DHCPv6 address assignment and it
> seems
> to be mediocre success:
> Linux (Dibbler) client was working almost alright - with some extension
> Windows Vista failed  - not really supporting longer prefix.
>
>
> for point-to-point links prefix longer than /64 was worked without any
> problem on Cisco boxes.
>
> Best Regards,
>
>
> Janos Mohacsi
> Network Engineer, Research Associate, Head of Network Planning and
> Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
>
>
>
>
>>
>>
>>
>> Best Regards,
>>
>> Jeffrey Dunn
>> Info Systems Eng., Lead
>>
>> Center for Enterprise Modernization
>> MITRE Corp.
>>
>> 301-429-5377 (Office)
>> 301-731-8862  (FAX)
>>
>>
>
>



From owner-v6ops@ops.ietf.org  Thu Jun  5 11:54:09 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 91D4B3A6D3A
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 11:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.559
X-Spam-Level: 
X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5
	tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4,
	RDNS_NONE=0.1]
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 Kv8Iu2tatwXL
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 11:54:08 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 906B328C22F
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 11:52:10 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4KXx-000GMi-Dm
	for v6ops-data@psg.com; Thu, 05 Jun 2008 18:50:49 +0000
Received: from [164.117.144.159] (helo=clyde.disa.mil)
	by psg.com with smtp (Exim 4.69 (FreeBSD))
	(envelope-from <Joseph.Holderman.ctr@disa.mil>)
	id 1K4KXt-000GLo-U3
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 18:50:47 +0000
Received: from platte.disanet.disa-u.mil ([209.22.68.152]) by clyde.disa.mil with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 5 Jun 2008 14:50:45 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: please drop me from the email group (UNCLASSIFIED)
Date: Thu, 5 Jun 2008 13:50:43 -0500
Content-Type: multipart/signed;
	boundary="----=_NextPart_000_0261_01C8C713.25F2E300";
	protocol="application/x-pkcs7-signature";
	micalg=SHA1
Message-ID: <9B4A0587AB273C49AFACA7F4EF457B150376102F@platte.disanet.disa-u.mil>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: please drop me from the email group (UNCLASSIFIED)
Thread-Index: AcjHPQyQQ5O/clhfQgSNTuHQ/tFPTQ==
From: "Holderman, Joseph D CTR DISA CONUS" <Joseph.Holderman.ctr@disa.mil>
To: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 05 Jun 2008 18:50:45.0242 (UTC) FILETIME=[0FD21DA0:01C8C73D]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0261_01C8C713.25F2E300
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Classification:  UNCLASSIFIED 
Caveats: NONE


Classification:  UNCLASSIFIED 
Caveats: NONE


------=_NextPart_000_0261_01C8C713.25F2E300
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQZzCCA3Aw
ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g
R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290
IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE
AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/
PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X
3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt
upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7
f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK
AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ
gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/
ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1
K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx
Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO
8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K
ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEMjCCAxqgAwIBAgIBGzANBgkqhkiG9w0BAQUFADBb
MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAK
BgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wNjA2MTQxNjM4NDVaFw0xMjA2
MTQxNTM4NDVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV
BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMTUwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALVplZ+ltuSfPPOfANWaFQf81jmu2da8VnbAJuA7j4GpaWaKSivC
tUpiUV7X+3qA40EWmsNm8+H8hIp8h/3Lu8gqpr3WF3NVGZeQe0SE/L9obop1agTOSBnTqsK5AB5k
VIhfO+Sb8MhHFVLfK8TKZaDBbAOvS2yD1rbpOGUWpRCDAgMBAAGjggGBMIIBfTAOBgNVHQ8BAf8E
BAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97oMaVxgmAcJYwHQYDVR0OBBYEFJW1jHirnVYz
PPRIo5xY7bFkioqeMAwGA1UdJAQFMAOAAQAwDwYDVR0TAQH/BAUwAwEB/zAwBgNVHSAEKTAnMAsG
CWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsKMIHZBgNVHR8EgdEwgc4wOKA2oDSG
Mmh0dHA6Ly9jcmwuZ2RzLmRpc2EubWlsL2dldGNybD9Eb0QlMjBSb290JTIwQ0ElMjAyMIGRoIGO
oIGLhoGIbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJj
b3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jZXJ0
aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAivmtXKcXvMhM
maUqn2rbLInqvnP5k7arBNP7ZNCixWqFx8geDysXKf2nGqg56j98pJOru320IGN5fwFGJIqoqV4u
MkxRhtmP9MJf3JLS30+TCMm5oMVyXHjLlgduyQsAeBe++eb5taWIfoHtR4+oi/76m0WCK0Jb+CGl
VRLWFrTzzWqbhtisMyUUDhU5kTZMwN0IsbhYdj57g2MaF9lGC51D8c7VZzMRmFTCeFEnVI0rN5sJ
Oz1KvwcqpnsU+BzjHv0d2GJnmariD8ymhs0qfad6vZcT5K/38Ylw7R3DJ0G2CEVwMIni16IO1mnd
1cRC1b6yy7Z2wWuZBF6+mfD1rDCCBDUwggOeoAMCAQICAxfB9zANBgkqhkiG9w0BAQUFADBdMQsw
CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV
BAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTE1MB4XDTA3MTEwOTAwMDAwMFoXDTEwMDkw
NDIzNTk1OVowgYAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV
BAsTA0RvRDEMMAoGA1UECxMDUEtJMRMwEQYDVQQLEwpDT05UUkFDVE9SMSYwJAYDVQQDEx1IT0xE
RVJNQU4uSk9TRVBILkQuMTE2ODQxMzMxNTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvyAW
EXxwveltgLmc1cZ0W35mZ1cmfbPDgVdpuZAO5oRgu9zS8eXhX6Jav4IFMPkx4Lxy6g9gSSYsB9ik
MFTErukOsNnCJtr+fzAa2bX13GyHOiF9+YFvXn7aw4dRU+iyzqJagdjx+xGREiGn1xfu/2GzjU+V
4gpS63cTUpfHzgECAwEAAaOCAd0wggHZMA4GA1UdDwEB/wQEAwIFIDAoBgNVHREEITAfgR1qb3Nl
cGguaG9sZGVybWFuLmN0ckBkaXNhLm1pbDAfBgNVHSMEGDAWgBSVtYx4q51WMzz0SKOcWO2xZIqK
njAdBgNVHQ4EFgQUeauutXeZXOxCs/WQqVVndLuzjF8wFgYDVR0gBA8wDTALBglghkgBZQIBCwkw
gdUGA1UdHwSBzTCByjA0oDKgMIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RE9EJTIwRU1B
SUwlMjBDQS0xNTCBkaCBjqCBi4aBiGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWlsL2NuJTNkRE9EJTIw
RU1BSUwlMjBDQS0xNSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1l
bnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwbQYIKwYBBQUHAQEE
YTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwl
MjBDQS0xNTAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwDQYJKoZIhvcNAQEFBQAD
gYEAbyXXOKOx7dnPoNC5USwdfpNLWAgcJW+E2eLMPHpiurosYHRJ8CN59H8k2ZeikEpTshJB/UGL
8k4IXtY9/Ryn0y5ouaQDCN4N7hdv3N5F+iIOnRImsMc//li1At3KZ3fGcdgHhK+J9K6R1Cv5eYnw
5chxvltskb86CeTZTrBOcTIwggSAMIID6aADAgECAgMXwfYwDQYJKoZIhvcNAQEFBQAwXTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQL
EwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0xNTAeFw0wNzExMDkwMDAwMDBaFw0xMDA5MDQy
MzU5NTlaMIGAMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL
EwNEb0QxDDAKBgNVBAsTA1BLSTETMBEGA1UECxMKQ09OVFJBQ1RPUjEmMCQGA1UEAxMdSE9MREVS
TUFOLkpPU0VQSC5ELjExNjg0MTMzMTUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIXKleQg
SXUG+tqAcWT+QB9h+QpTGsR6i1hP7WYHq1O7PeM7a5dLOpeL7nTCrTjGHkId4GoIugpFG/j2r2Dt
wfWZoWCf+N3zKFDY60yf0AM0OphfdUniT+cAEy5wpl/Z0Qj1A6QgwVbI/JPQ81Ismo4oNcaY/Ure
BUVAzm/vzSThAgMBAAGjggIoMIICJDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUlbWMeKud
VjM89EijnFjtsWSKip4wHQYDVR0OBBYEFNS9Z5jgVzDh5WhfaW8k+yxo8NwWMBYGA1UdIAQPMA0w
CwYJYIZIAWUCAQsJMIHVBgNVHR8Egc0wgcowNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0
Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMTUwgZGggY6ggYuGgYhsZGFwOi8vY3JsLmdkcy5kaXNhLm1p
bC9jbiUzZERPRCUyMEVNQUlMJTIwQ0EtMTUlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUu
Uy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5
MCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsGAQUFBwMEBggrBgEFBQcDAjBIBgNVHREEQTA/gR1q
b3NlcGguaG9sZGVybWFuLmN0ckBkaXNhLm1pbKAeBgorBgEEAYI3FAIDoBAMDjExNjg0MTMzMTVA
bWlsMG0GCCsGAQUFBwEBBGEwXzA7BggrBgEFBQcwAoYvaHR0cDovL2NybC5kaXNhLm1pbC9nZXRz
aWduP0RPRCUyMEVNQUlMJTIwQ0EtMTUwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWls
MA0GCSqGSIb3DQEBBQUAA4GBAGcdPRKpqsyNrMARNEsoe/pXdRsGOsgVhxWLAwg6sPXxCpy51P2F
SwRVQxDSFciV2AvRNgEVT28B3I521ndSLpmB488iyNawL7vDQHPg+U5Fw8iMDEhSo4F7rszKqU61
gzJmXhveG8hHekXfaJ0+MP4q3d0Ox7EHvklr76xgBb+9MYICsTCCAq0CAQEwZDBdMQswCQYDVQQG
EwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BL
STEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTE1AgMXwfYwCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNjA1MTg1MDQzWjAjBgkqhkiG9w0B
CQQxFgQUjIWijVWD9eBpcbVD3kCOcTKDKG8wWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN
AgUwcwYJKwYBBAGCNxAEMWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t
ZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTE1
AgMXwfcwdQYLKoZIhvcNAQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv
dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg
Q0EtMTUCAxfB9zANBgkqhkiG9w0BAQEFAASBgCN5m4bGOg6dBeShaLcCuEZXZrFyQFr42Jv88ZNL
RchekFVH1IjTGzUnWxE4zV6vT3FrC0XLhpTl7+r9No3DIc5MTvJQUVrCvfYjfYNVzhdJh3p5XDyw
vjjwCPWOHEaZpDNpLPkBGYrISX5xTQKMgWFK+MCfQibxu1QoT2oQzlabAAAAAAAA

------=_NextPart_000_0261_01C8C713.25F2E300--



From owner-v6ops@ops.ietf.org  Thu Jun  5 13:58:07 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BE6E53A6819
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 13:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level: 
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5
	tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 Xx5gXU-MYaLA
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 13:58:07 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 898013A67B0
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 13:58:06 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4MRX-000DQz-0o
	for v6ops-data@psg.com; Thu, 05 Jun 2008 20:52:19 +0000
Received: from [83.149.65.1] (helo=sequoia.muada.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <iljitsch@muada.com>)
	id 1K4MRT-000DPY-R6
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 20:52:17 +0000
Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged))
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m55KniVO051096
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 5 Jun 2008 22:49:55 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Cc: "Dunn, Jeffrey H." <jdunn@mitre.org>, v6ops@ops.ietf.org
Message-Id: <0B4E00E5-D385-4719-A924-B243A4C90BB0@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: bmanning@vacation.karoshi.com
In-Reply-To: <20080605171427.GA8269@vacation.karoshi.com.>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Use of extended prefix lengths
Date: Thu, 5 Jun 2008 22:50:00 +0200
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605171427.GA8269@vacation.karoshi.com.>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 5 jun 2008, at 19:14, bmanning@vacation.karoshi.com wrote:

> you mean longer than /64?
> I have built a network out of a /96, using /120's for subnets.
> you have to turn -off- all the autoconfig crap - but it is doable.
> dhcpv6 would have been a real help then.

Just make sure you don't use the all-zeros address because that's the  
all-routers anycast address even though many routers don't care.  
Nightmare scenario would be that they start caring after some update.  
The top 128 addresses of a subnet are reserved anycast addresses too,  
so /120 or longer isn't ideal either. /112 is good because then the  
last four hex digits are your subnet. However, you can also often just  
use link locals, routing protocols only use link locals, anyway.

Note that DHCPv6 will only give you address assignment (if supported  
by both the client and the server) but it won't give you a subnet  
prefix length or a default router, for this you still need router  
advertisements. But you REALLY don't want to use non-/64 subnets  
unless you manually configure them, trust me.



From owner-v6ops@ops.ietf.org  Thu Jun  5 14:30:19 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D0AB93A687F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 14:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.518
X-Spam-Level: 
X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5
	tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 oXeDPWmgn-Ud
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 14:30:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id EEED43A6870
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 14:30:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4N0R-000KRL-IL
	for v6ops-data@psg.com; Thu, 05 Jun 2008 21:28:23 +0000
Received: from [192.203.228.196] (helo=elvis.mu.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <billf@elvis.mu.org>)
	id 1K4N0O-000KQh-Th
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 21:28:22 +0000
Received: by elvis.mu.org (Postfix, from userid 1098)
	id 9CE201A4D83; Thu,  5 Jun 2008 14:28:20 -0700 (PDT)
Date: Thu, 5 Jun 2008 14:28:20 -0700
From: bill fumerola <billf@mu.org>
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
Cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
Message-ID: <20080605212820.GL28936@elvis.mu.org>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080605192034.H99897@mignon.ki.iif.hu>
User-Agent: Mutt/1.4.2.3i
X-Operating-System: FreeBSD 6.3-MUORG-20080227 amd64
X-PGP-DEAD-Key: 1024D/7F868268
X-PGP-DEAD-Fingerprint: 5B2D 908E 4C2B F253 DAEB  FC01 8436 B70B 7F86 8268
X-PGP-Key: 1024D/AE9EB579
X-PGP-Fingerprint: 2E51 E3DE 2C52 C84D 750F  8ADE 1F18 67FB AE9E B579
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Thu, Jun 05, 2008 at 07:26:00PM +0200, Mohacsi Janos wrote:
> for point-to-point links prefix longer than /64 was worked without any 
> problem on Cisco boxes.

for internal point-to-point links, using ospfv3 + link-local addresses
+ /128s on loopbacks has worked well for me. for point-to-point on the
edge, i've used /64s down to /120s. depending on your IGP, using global
addresses on point-to-point may have its benefits.


-- bill



From owner-v6ops@ops.ietf.org  Thu Jun  5 15:09:18 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 590BD3A68ED
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 15:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level: 
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_LOW=-1,
	RDNS_NONE=0.1]
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 LlRR161bd49A
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 15:09:17 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 7431F3A6877
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 15:09:17 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4Nas-0002IC-0r
	for v6ops-data@psg.com; Thu, 05 Jun 2008 22:06:02 +0000
Received: from [130.215.36.91] (helo=mail1.wpi.edu)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <cra@WPI.EDU>)
	id 1K4Nao-0002H4-MU
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 22:06:00 +0000
Received: from mcafee.wpi.edu (MCAFEE.WPI.EDU [130.215.36.86])
	by mail1.wpi.edu (8.14.3.Gamma0/8.14.3.Gamma0) with SMTP id m55M5wHf031522
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 18:05:58 -0400
Received: from (130.215.36.186) by mcafee.wpi.edu via smtp
	 id 7883_937726ee_334b_11dd_820b_0013725b2d50;
	Thu, 05 Jun 2008 19:05:57 -0300
Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21])
	by SMTP.WPI.EDU (8.13.8/8.13.8) with ESMTP id m55M5v5D015771
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 18:05:57 -0400
	(envelope-from cra@WPI.EDU)
Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1])
	by angus.ind.WPI.EDU (8.14.1/8.13.8) with ESMTP id m55M5v0r023429
	for <v6ops@ops.ietf.org>; Thu, 5 Jun 2008 18:05:57 -0400
Received: (from cra@localhost)
	by angus.ind.WPI.EDU (8.14.1/8.14.1/Submit) id m55M5v0o023428
	for v6ops@ops.ietf.org; Thu, 5 Jun 2008 18:05:57 -0400
X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f
Date: Thu, 5 Jun 2008 18:05:57 -0400
From: Chuck Anderson <cra@WPI.EDU>
To: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
Message-ID: <20080605220557.GD10754@angus.ind.WPI.EDU>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu> <20080605212820.GL28936@elvis.mu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080605212820.GL28936@elvis.mu.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Thu, Jun 05, 2008 at 02:28:20PM -0700, bill fumerola wrote:
> On Thu, Jun 05, 2008 at 07:26:00PM +0200, Mohacsi Janos wrote:
> > for point-to-point links prefix longer than /64 was worked without any 
> > problem on Cisco boxes.
> 
> for internal point-to-point links, using ospfv3 + link-local addresses
> + /128s on loopbacks has worked well for me. for point-to-point on the
> edge, i've used /64s down to /120s. depending on your IGP, using global
> addresses on point-to-point may have its benefits.

How does traceroute work when using link-local addressing on 
point-to-point links?



From owner-v6ops@ops.ietf.org  Thu Jun  5 16:18:09 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D69A23A68B6
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 16:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5
	tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 XDkwNtSFgTmz
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 16:18:08 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 235EA3A6783
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 16:18:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4OeW-000FSw-Eq
	for v6ops-data@psg.com; Thu, 05 Jun 2008 23:13:52 +0000
Received: from [192.203.228.196] (helo=elvis.mu.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <billf@elvis.mu.org>)
	id 1K4OeT-000FOC-Fz
	for v6ops@ops.ietf.org; Thu, 05 Jun 2008 23:13:50 +0000
Received: by elvis.mu.org (Postfix, from userid 1098)
	id 3B43E1A4D8E; Thu,  5 Jun 2008 16:13:27 -0700 (PDT)
Date: Thu, 5 Jun 2008 16:13:27 -0700
From: bill fumerola <billf@mu.org>
To: Chuck Anderson <cra@WPI.EDU>
Cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
Message-ID: <20080605231327.GN28936@elvis.mu.org>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu> <20080605212820.GL28936@elvis.mu.org> <20080605220557.GD10754@angus.ind.WPI.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080605220557.GD10754@angus.ind.WPI.EDU>
User-Agent: Mutt/1.4.2.3i
X-Operating-System: FreeBSD 6.3-MUORG-20080227 amd64
X-PGP-DEAD-Key: 1024D/7F868268
X-PGP-DEAD-Fingerprint: 5B2D 908E 4C2B F253 DAEB  FC01 8436 B70B 7F86 8268
X-PGP-Key: 1024D/AE9EB579
X-PGP-Fingerprint: 2E51 E3DE 2C52 C84D 750F  8ADE 1F18 67FB AE9E B579
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Thu, Jun 05, 2008 at 06:05:57PM -0400, Chuck Anderson wrote:
> On Thu, Jun 05, 2008 at 02:28:20PM -0700, bill fumerola wrote:
> > for internal point-to-point links, using ospfv3 + link-local addresses
> > + /128s on loopbacks has worked well for me. for point-to-point on the
> > edge, i've used /64s down to /120s. depending on your IGP, using global
> > addresses on point-to-point may have its benefits.
> 
> How does traceroute work when using link-local addressing on 
> point-to-point links?

rtr1.ash>sh ipv6 route 2001:500:2F::F
B   2001:500:2F::/48 [200/0]
     via 2620:0:CCC:1::1    
rtr1.ash>sh ipv6 route 2620:0:CCC:1::1
O   2620:0:CCC:1::1/128 [110/1]
    via FE80::217:FFF:FE1C:BC1B, Tunnel3800 
rtr1.ash>sh ipv6 int tun3800
Tunnel3800 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::219:7FF:FE23:7C1B 
  Description: NYC/ASH
  No global unicast address is configured
[...]
rtr1.ash>traceroute 2001:500:2F::F

Type escape sequence to abort.
Tracing the route to f.root-servers.net (2001:500:2F::F)

  1 2620:0:CCC:0:217:FFF:FE1C:BC1B 8 msec 8 msec 8 msec
  2 2001:504:1::A502:7319:1 8 msec 8 msec 8 msec
  3 f.root-servers.net (2001:500:2F::F) 8 msec 4 msec 80 msec

and...

rtr1.nyc#sh ipv6 int br
GigabitEthernet0/0         [up/up]
    unassigned
GigabitEthernet0/0.1       [up/up]
    FE80::217:FFF:FE1C:BC1B
    2620:0:CCC:0:217:FFF:FE1C:BC1B  <-- used in traceroute
GigabitEthernet0/2         [up/up]
    FE80::217:FFF:FE1C:BC19
    2001:504:1::A503:6692:1
Loopback0                  [up/up]
    FE80::217:FFF:FE1C:BC1B
    2620:0:CCC:1::1
[....]
Tunnel3800                 [up/up]
    FE80::217:FFF:FE1C:BC1B
Tunnel3802                 [up/up]
    FE80::217:FFF:FE1C:BC1B

in this case it uses an available global address. probably the lowest
number. (on this box, 2620:0:CCC:0:: < 2620:0:CCC:1::)

rtr1.nyc#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
rtr1.nyc(config)#int tun3800
rtr1.nyc(config-if)#ipv6 unnumbered lo0
rtr1.nyc(config-if)#^Z
rtr1.nyc#

Tunnel3800                 [up/up]
    FE80::217:FFF:FE1C:BC1B
    unnumbered (Loopback0)

and now...

rtr1.ash#traceroute 2001:500:2F::F         

Type escape sequence to abort.
Tracing the route to f.root-servers.net (2001:500:2F::F)

  1 2620:0:CCC:1::1 8 msec 8 msec 8 msec
  2 2001:504:1::A502:7319:1 4 msec 8 msec 12 msec
  3 f.root-servers.net (2001:500:2F::F) 8 msec 8 msec 8 msec
rtr1.ash#

... and now it uses the loopback.

-- bill



From owner-v6ops@ops.ietf.org  Thu Jun  5 22:09:13 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7532A3A695C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu,  5 Jun 2008 22:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 GdrSeK+i1Q8T
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu,  5 Jun 2008 22:09:12 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 973203A69C9
	for <v6ops-archive@lists.ietf.org>; Thu,  5 Jun 2008 22:09:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4U6Y-0004oX-NC
	for v6ops-data@psg.com; Fri, 06 Jun 2008 05:03:10 +0000
Received: from [2001:738:0:411::241] (helo=mail.ki.iif.hu)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <mohacsi@niif.hu>)
	id 1K4U6U-0004kD-L4
	for v6ops@ops.ietf.org; Fri, 06 Jun 2008 05:03:08 +0000
Received: from localhost (localhost [IPv6:::1])
	by mail.ki.iif.hu (Postfix) with ESMTP id 05C44849CA;
	Fri,  6 Jun 2008 07:02:59 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu
Received: from mail.ki.iif.hu ([127.0.0.1])
	by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Hb0ZSEw1Ob5n; Fri,  6 Jun 2008 07:02:56 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002)
	id 303F0849C8; Fri,  6 Jun 2008 07:02:56 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by mail.ki.iif.hu (Postfix) with ESMTP id 2EF9C8493B;
	Fri,  6 Jun 2008 07:02:56 +0200 (CEST)
Date: Fri, 6 Jun 2008 07:02:56 +0200 (CEST)
From: Mohacsi Janos <mohacsi@niif.hu>
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Chuck Anderson <cra@WPI.EDU>
cc: v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths
In-Reply-To: <20080605220557.GD10754@angus.ind.WPI.EDU>
Message-ID: <20080606065747.S57107@mignon.ki.iif.hu>
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG>
 <20080605192034.H99897@mignon.ki.iif.hu> <20080605212820.GL28936@elvis.mu.org>
 <20080605220557.GD10754@angus.ind.WPI.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>




On Thu, 5 Jun 2008, Chuck Anderson wrote:

> On Thu, Jun 05, 2008 at 02:28:20PM -0700, bill fumerola wrote:
>> On Thu, Jun 05, 2008 at 07:26:00PM +0200, Mohacsi Janos wrote:
>>> for point-to-point links prefix longer than /64 was worked without any
>>> problem on Cisco boxes.
>>
>> for internal point-to-point links, using ospfv3 + link-local addresses
>> + /128s on loopbacks has worked well for me. for point-to-point on the
>> edge, i've used /64s down to /120s. depending on your IGP, using global
>> addresses on point-to-point may have its benefits.
>
> How does traceroute work when using link-local addressing on
> point-to-point links?

Very well. It will pick up the one the global IPv6 address of the box as 
a sourceaddress of ICMPv6 TTL exceeded. If you 
want make it detereministic set up unnumbered to ipv6 loopback. In case of 
cisco routers e.g.:

interface GigabitEthernet3/4
  mtu 9216
  ipv6 unnumbered Loopback0      <------
  ipv6 enable
  ipv6 ospf network point-to-point

Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

>
>



From owner-v6ops@ops.ietf.org  Fri Jun  6 04:11:17 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 49A243A67D9
	for <ietfarch-v6ops-archive@core3.amsl.com>; Fri,  6 Jun 2008 04:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level: 
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5
	tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 Ne5hlBXkEa8f
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Fri,  6 Jun 2008 04:11:16 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 191A83A6C8E
	for <v6ops-archive@lists.ietf.org>; Fri,  6 Jun 2008 04:11:16 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4Zjw-0001By-Nh
	for v6ops-data@psg.com; Fri, 06 Jun 2008 11:04:12 +0000
Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com)
	by psg.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.69 (FreeBSD))
	(envelope-from <rdroms@cisco.com>)
	id 1K4Zjo-00018e-O3
	for v6ops@ops.ietf.org; Fri, 06 Jun 2008 11:04:10 +0000
X-IronPort-AV: E=Sophos;i="4.27,600,1204520400"; 
   d="scan'208";a="10304696"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
  by rtp-iport-1.cisco.com with ESMTP; 06 Jun 2008 07:03:53 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m56B3rMV028598;
	Fri, 6 Jun 2008 07:03:53 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102])
	by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m56B3rMf006627;
	Fri, 6 Jun 2008 11:03:53 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 6 Jun 2008 07:03:53 -0400
Received: from [192.168.1.105] ([10.86.249.9]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 6 Jun 2008 07:03:52 -0400
Cc: Ralph Droms <rdroms@cisco.com>, "Mohacsi Janos" <mohacsi@niif.hu>,
        <v6ops@ops.ietf.org>
Message-Id: <BA504849-932E-4F37-8BCD-3308BA8F0067@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
In-Reply-To: <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Use of extended prefix lengths
Date: Fri, 6 Jun 2008 07:03:52 -0400
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu> <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 06 Jun 2008 11:03:53.0116 (UTC) FILETIME=[01B4A5C0:01C8C7C5]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1620; t=1212750233; x=1213614233;
	c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20<rdroms@cisco.com>
	|Subject:=20Re=3A=20Use=20of=20extended=20prefix=20lengths
	|Sender:=20
	|To:=20=22Dunn,=20Jeffrey=20H.=22=20<jdunn@mitre.org>;
	bh=ncPsDpvwRQ4uP5DD0cEdnlyTG3acxBPfdmAkR6d3r7k=;
	b=Qw+guQ5ZYVbJJtSXAQLuQHEYSuHcfPSPudd2sL4KarXwQzbSg+vWyw9uVD
	rCpz/8G6vwwcDvpZSbAgmvPKvLiM/HbKMQhRoFE4O1b+o3OBOapebumvLv0P
	JvQ990/7FK;
Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

The DHCP server in Cisco's CNR supports prefixes of any length (up to / 
128).

- Ralph

On Jun 5, 2008, at Jun 5, 2008,1:35 PM, Dunn, Jeffrey H. wrote:

> Janos,
>
> Which server did he use?
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> -----Original Message-----
> From: Mohacsi Janos [mailto:mohacsi@niif.hu]
> Sent: Thursday, June 05, 2008 1:26 PM
> To: Dunn, Jeffrey H.
> Cc: v6ops@ops.ietf.org
> Subject: Re: Use of extended prefix lengths
>
>
>
>
> On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:
>
>> Colleagues,
>>
>>
>>
>> I was discussing the possibility of using IPv6 prefix lengths greater
>> than 64 bits with some colleagues and wondered if anyone had any
>> experience with doing so.  Specifically, has anyone tried it?
>> Thoughts?
>
> One of my colleague tried /126 with DHCPv6 address assignment and it
> seems
> to be mediocre success:
> Linux (Dibbler) client was working almost alright - with some  
> extension
> Windows Vista failed  - not really supporting longer prefix.
>
>
> for point-to-point links prefix longer than /64 was worked without any
> problem on Cisco boxes.
>
> Best Regards,
>
>
> Janos Mohacsi
> Network Engineer, Research Associate, Head of Network Planning and
> Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
>
>
>
>
>>
>>
>>
>> Best Regards,
>>
>> Jeffrey Dunn
>> Info Systems Eng., Lead
>>
>> Center for Enterprise Modernization
>> MITRE Corp.
>>
>> 301-429-5377 (Office)
>> 301-731-8862  (FAX)
>>
>>
>




From owner-v6ops@ops.ietf.org  Fri Jun  6 04:43:44 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3E0EA3A6CFA
	for <ietfarch-v6ops-archive@core3.amsl.com>; Fri,  6 Jun 2008 04:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level: 
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[AWL=0.233,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 ZAHf-6xYlZ6W
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Fri,  6 Jun 2008 04:43:40 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 0676B3A6CC9
	for <v6ops-archive@lists.ietf.org>; Fri,  6 Jun 2008 04:43:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4aKo-0009J1-LL
	for v6ops-data@psg.com; Fri, 06 Jun 2008 11:42:18 +0000
Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jdunn@mitre.org>)
	id 1K4aKY-0009E7-Nt
	for v6ops@ops.ietf.org; Fri, 06 Jun 2008 11:42:04 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m56Bg1N5007588
	for <v6ops@ops.ietf.org>; Fri, 6 Jun 2008 07:42:02 -0400
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m56Bg17k007584;
	Fri, 6 Jun 2008 07:42:01 -0400
Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 6 Jun 2008 07:42:01 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Use of extended prefix lengths
Date: Fri, 6 Jun 2008 07:41:55 -0400
Message-ID: <0AC4B700F00DBB4C94F95727E09914140116FDC3@IMCSRV7.MITRE.ORG>
In-Reply-To: <BA504849-932E-4F37-8BCD-3308BA8F0067@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Use of extended prefix lengths
Thread-Index: AcjHxQMpHr1KyvtETdC137ZHQjOwRAABTy2g
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu> <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG> <BA504849-932E-4F37-8BCD-3308BA8F0067@cisco.com>
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: "Ralph Droms" <rdroms@cisco.com>
Cc: "Mohacsi Janos" <mohacsi@niif.hu>, <v6ops@ops.ietf.org>,
        "Dunn, Jeffrey H." <jdunn@mitre.org>
X-OriginalArrivalTime: 06 Jun 2008 11:42:01.0741 (UTC) FILETIME=[55D51BD0:01C8C7CA]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Ralph,

Many thanks for the information.  Does this include prefix delegation?=20

Best Regards,
=20
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]=20
Sent: Friday, June 06, 2008 7:04 AM
To: Dunn, Jeffrey H.
Cc: Ralph Droms; Mohacsi Janos; v6ops@ops.ietf.org
Subject: Re: Use of extended prefix lengths

The DHCP server in Cisco's CNR supports prefixes of any length (up to /

128).

- Ralph

On Jun 5, 2008, at Jun 5, 2008,1:35 PM, Dunn, Jeffrey H. wrote:

> Janos,
>
> Which server did he use?
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> -----Original Message-----
> From: Mohacsi Janos [mailto:mohacsi@niif.hu]
> Sent: Thursday, June 05, 2008 1:26 PM
> To: Dunn, Jeffrey H.
> Cc: v6ops@ops.ietf.org
> Subject: Re: Use of extended prefix lengths
>
>
>
>
> On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:
>
>> Colleagues,
>>
>>
>>
>> I was discussing the possibility of using IPv6 prefix lengths
greater
>> than 64 bits with some colleagues and wondered if anyone had any
>> experience with doing so.  Specifically, has anyone tried it?
>> Thoughts?
>
> One of my colleague tried /126 with DHCPv6 address assignment and it
> seems
> to be mediocre success:
> Linux (Dibbler) client was working almost alright - with some =20
> extension
> Windows Vista failed  - not really supporting longer prefix.
>
>
> for point-to-point links prefix longer than /64 was worked without
any
> problem on Cisco boxes.
>
> Best Regards,
>
>
> Janos Mohacsi
> Network Engineer, Research Associate, Head of Network Planning and
> Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
>
>
>
>
>>
>>
>>
>> Best Regards,
>>
>> Jeffrey Dunn
>> Info Systems Eng., Lead
>>
>> Center for Enterprise Modernization
>> MITRE Corp.
>>
>> 301-429-5377 (Office)
>> 301-731-8862  (FAX)
>>
>>
>




From owner-v6ops@ops.ietf.org  Fri Jun  6 04:44:03 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1693A3A6CCA
	for <ietfarch-v6ops-archive@core3.amsl.com>; Fri,  6 Jun 2008 04:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Level: 
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[AWL=0.186,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 qQpr+utENgPG
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Fri,  6 Jun 2008 04:43:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id F0FE13A6D08
	for <v6ops-archive@lists.ietf.org>; Fri,  6 Jun 2008 04:43:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4aLx-0009T2-ML
	for v6ops-data@psg.com; Fri, 06 Jun 2008 11:43:29 +0000
Received: from [129.83.20.191] (helo=smtp-bedford.mitre.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jdunn@mitre.org>)
	id 1K4aLY-0009Q5-Tc
	for v6ops@ops.ietf.org; Fri, 06 Jun 2008 11:43:18 +0000
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m56Bh4qe010166
	for <v6ops@ops.ietf.org>; Fri, 6 Jun 2008 07:43:04 -0400
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4])
	by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m56Bh4NQ010162
	for <v6ops@ops.ietf.org>; Fri, 6 Jun 2008 07:43:04 -0400
Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 6 Jun 2008 07:43:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Subject: FW: (Microsoft Windows DHCP Team Blog) : Use of extended length prefixes
Date: Fri, 6 Jun 2008 07:42:20 -0400
Message-ID: <0AC4B700F00DBB4C94F95727E09914140116FDC4@IMCSRV7.MITRE.ORG>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: (Microsoft Windows DHCP Team Blog) : Use of extended length prefixes
Thread-Index: AcjHM9vlPJcqAXf4Tq6bbmhiawJJUwAaG1cgAAtx9MA=
From: "Dunn, Jeffrey H." <jdunn@mitre.org>
To: <v6ops@ops.ietf.org>
Cc: "Dunn, Jeffrey H." <jdunn@mitre.org>
X-OriginalArrivalTime: 06 Jun 2008 11:43:04.0224 (UTC) FILETIME=[7B134200:01C8C7CA]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Q29sbGVhZ3VlcywNCg0KTWFueSB0aGFua3MgdG8gUmFscGggRHJvbXMgZm9yIHZlcmlmeWluZyB0
aGF0IENpc2NvIGRvZXMgc3VwcG9ydA0KZXh0ZW5kZWQgcHJlZml4ZXMuICBBcyB5b3UgY2FuIHNl
ZSBmcm9tIHRoZSBmb3J3YXJkZWQgZS1tYWlsIGJlbG93LA0KTWljcm9zb2Z0IGRvZXMgbm90IDst
KA0KDQpCZXN0IFJlZ2FyZHMsDQogDQpKZWZmcmV5IER1bm4NCkluZm8gU3lzdGVtcyBFbmcuLCBM
ZWFkDQpNSVRSRSBDb3Jwb3JhdGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IE1hbnUgSmVld2FuaSBbbWFpbHRvOm1hbnVqQG1pY3Jvc29mdC5jb21dIA0KU2VudDogRnJp
ZGF5LCBKdW5lIDA2LCAyMDA4IDI6MTMgQU0NClRvOiBEdW5uLCBKZWZmcmV5IEguOyBESENQIEJs
b2dnZXJzDQpTdWJqZWN0OiBSRTogKE1pY3Jvc29mdCBXaW5kb3dzIERIQ1AgVGVhbSBCbG9nKSA6
IFVzZSBvZiBleHRlbmRlZA0KbGVuZ3RoIHByZWZpeGVzDQoNCkhpIEplZmYsDQoNCldpbmRvd3Mg
c2VydmVyIDIwMDggREhDUCBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBwcmVmaXggb3RoZXIgdGhl
biA2NA0KYml0Lg0KDQpUaGFua3MsDQpNYW51DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBqZHVubkBtaXRyZS5vcmcgW21haWx0bzpqZHVubkBtaXRyZS5vcmddDQpTZW50OiAw
NSBKdW5lIDIwMDggMjM6MTUNClRvOiBESENQIEJsb2dnZXJzDQpTdWJqZWN0OiAoTWljcm9zb2Z0
IFdpbmRvd3MgREhDUCBUZWFtIEJsb2cpIDogVXNlIG9mIGV4dGVuZGVkIGxlbmd0aA0KcHJlZml4
ZXMNCkltcG9ydGFuY2U6IEhpZ2gNCg0KDQpHcmVldGluZ3MsDQoNCkkgYW0gaW50ZXJlc3RlZCBp
biBhc3NvY2lhdGluZyBleHRlbmRlZCBsZW5ndGggKGxvbmdlciB0aGFuIDY0IGJpdCkNCnByZWZp
eGVzIHdpdGggbGlua3Mgb3IgbGluayBhZGRycmVzc2VzLiAgV2lsbCB0aGUgV0lOIFNWUiAyMDA4
IERIQ1B2Ng0Kc2VydmVyIHN1cHBvcnQgcHJlZml4ZXMgbG9uZ2VyIHRoYW4gNjQgYml0cz8NCg0K
UmVnYXJkcywNCg0KSmVmZg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhp
cyBtZXNzYWdlIHdhcyBnZW5lcmF0ZWQgZnJvbSBhIGNvbnRhY3QgZm9ybSBhdDoNCmh0dHA6Ly9i
bG9ncy50ZWNobmV0LmNvbS90ZWFtZGhjcC9kZWZhdWx0LmFzcHgNCkl0IHdhcyBzdWJtaXR0ZWQg
YnkgSmVmZnJleSBEdW5uIChqZHVubkBtaXRyZS5vcmcpDQoNCllvdXIgY29udGFjdCBpbmZvcm1h
dGlvbiB3YXMgbm90IHNoYXJlZCB3aXRoIHRoZSB1c2VyLg0K



From owner-v6ops@ops.ietf.org  Fri Jun  6 07:24:38 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B975B3A6D79
	for <ietfarch-v6ops-archive@core3.amsl.com>; Fri,  6 Jun 2008 07:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.495
X-Spam-Level: 
X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 xew+mbA-Dakb
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Fri,  6 Jun 2008 07:24:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 72C203A6D72
	for <v6ops-archive@lists.ietf.org>; Fri,  6 Jun 2008 07:24:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4clP-000Dfa-V8
	for v6ops-data@psg.com; Fri, 06 Jun 2008 14:17:55 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.69 (FreeBSD))
	(envelope-from <rdroms@cisco.com>)
	id 1K4cl2-000DcG-Hi
	for v6ops@ops.ietf.org; Fri, 06 Jun 2008 14:17:44 +0000
X-IronPort-AV: E=Sophos;i="4.27,600,1204531200"; 
   d="scan'208";a="54296775"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
  by sj-iport-2.cisco.com with ESMTP; 06 Jun 2008 07:17:32 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m56EHW3d018935;
	Fri, 6 Jun 2008 07:17:32 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102])
	by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m56EHV6N004946;
	Fri, 6 Jun 2008 14:17:31 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 6 Jun 2008 10:17:31 -0400
Received: from [161.44.65.201] ([161.44.65.201]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 6 Jun 2008 10:17:30 -0400
Cc: Ralph Droms <rdroms@cisco.com>, "Mohacsi Janos" <mohacsi@niif.hu>,
        <v6ops@ops.ietf.org>
Message-Id: <38E685C8-8425-4BB6-9B28-D1352CEA1575@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
In-Reply-To: <0AC4B700F00DBB4C94F95727E09914140116FDC3@IMCSRV7.MITRE.ORG>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Use of extended prefix lengths
Date: Fri, 6 Jun 2008 10:17:30 -0400
References: <0AC4B700F00DBB4C94F95727E09914140116FCFA@IMCSRV7.MITRE.ORG> <20080605192034.H99897@mignon.ki.iif.hu> <0AC4B700F00DBB4C94F95727E09914140116FD0D@IMCSRV7.MITRE.ORG> <BA504849-932E-4F37-8BCD-3308BA8F0067@cisco.com> <0AC4B700F00DBB4C94F95727E09914140116FDC3@IMCSRV7.MITRE.ORG>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 06 Jun 2008 14:17:31.0109 (UTC) FILETIME=[0E91B150:01C8C7E0]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2225; t=1212761852; x=1213625852;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20<rdroms@cisco.com>
	|Subject:=20Re=3A=20Use=20of=20extended=20prefix=20lengths
	|Sender:=20;
	bh=3uvrS1xRFNaV+HFFR253FUxQmWImsXJijoRgvSi4M4o=;
	b=V4RsNicigQcJPJDR+yqf0O6t7oytoQTzI7NRUX/SE0EweSSxnjkyX66kKg
	52jN01zbvVLYL2G9cKNZ92eg1lqqXl/XpTSn6jCPZTPtI1ckH6JJ4ZhyzFcz
	/CIOUtuJ8A;
Authentication-Results: sj-dkim-2; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Yes...

- Ralph

On Jun 6, 2008, at Jun 6, 2008,7:41 AM, Dunn, Jeffrey H. wrote:

> Ralph,
>
> Many thanks for the information.  Does this include prefix delegation?
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Friday, June 06, 2008 7:04 AM
> To: Dunn, Jeffrey H.
> Cc: Ralph Droms; Mohacsi Janos; v6ops@ops.ietf.org
> Subject: Re: Use of extended prefix lengths
>
> The DHCP server in Cisco's CNR supports prefixes of any length (up  
> to /
>
> 128).
>
> - Ralph
>
> On Jun 5, 2008, at Jun 5, 2008,1:35 PM, Dunn, Jeffrey H. wrote:
>
>> Janos,
>>
>> Which server did he use?
>>
>> Best Regards,
>>
>> Jeffrey Dunn
>> Info Systems Eng., Lead
>> MITRE Corporation.
>>
>> -----Original Message-----
>> From: Mohacsi Janos [mailto:mohacsi@niif.hu]
>> Sent: Thursday, June 05, 2008 1:26 PM
>> To: Dunn, Jeffrey H.
>> Cc: v6ops@ops.ietf.org
>> Subject: Re: Use of extended prefix lengths
>>
>>
>>
>>
>> On Thu, 5 Jun 2008, Dunn, Jeffrey H. wrote:
>>
>>> Colleagues,
>>>
>>>
>>>
>>> I was discussing the possibility of using IPv6 prefix lengths
> greater
>>> than 64 bits with some colleagues and wondered if anyone had any
>>> experience with doing so.  Specifically, has anyone tried it?
>>> Thoughts?
>>
>> One of my colleague tried /126 with DHCPv6 address assignment and it
>> seems
>> to be mediocre success:
>> Linux (Dibbler) client was working almost alright - with some
>> extension
>> Windows Vista failed  - not really supporting longer prefix.
>>
>>
>> for point-to-point links prefix longer than /64 was worked without
> any
>> problem on Cisco boxes.
>>
>> Best Regards,
>>
>>
>> Janos Mohacsi
>> Network Engineer, Research Associate, Head of Network Planning and
>> Projects
>> NIIF/HUNGARNET, HUNGARY
>> Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
>>
>>
>>
>>
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> Jeffrey Dunn
>>> Info Systems Eng., Lead
>>>
>>> Center for Enterprise Modernization
>>> MITRE Corp.
>>>
>>> 301-429-5377 (Office)
>>> 301-731-8862  (FAX)
>>>
>>>
>>
>




From c.mugla@apnea.com.tr  Fri Jun  6 07:31:57 2008
Return-Path: <c.mugla@apnea.com.tr>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 327763A6BAE;
	Fri,  6 Jun 2008 07:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -65.584
X-Spam-Level: 
X-Spam-Status: No, score=-65.584 tagged_above=-999 required=5
	tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, GB_ROLEX=5,
	HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RDNS_NONE=0.1,
	SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062,
	SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666,
	TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 BhfzNThoEsBM; Fri,  6 Jun 2008 07:31:56 -0700 (PDT)
Received: from 190-174-146-96.speedy.com.ar (unknown [190.174.146.96])
	by core3.amsl.com (Postfix) with SMTP id ADD333A6D7D;
	Fri,  6 Jun 2008 07:31:43 -0700 (PDT)
X-Originating-IP: 48.12.192.100 by smtp.190.174.146.96;  Fri, 06 Jun 2008 10:31:52 -0500
Message-ID: <yqgnfyTPSUSTtsv-area@ietf.org>
From: "Hans Cross" <tsv-area@ietf.org>
Reply-To: "Hans Cross" <tsv-area@ietf.org>
To: tsv-area@ietf.org
Subject: Impressive Glashutte timepieces
Date: Fri, 06 Jun 2008 10:31:52 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers.
http://xolucudyfuf31.blogspot.com/

Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal!
http://xolucudyfuf31.blogspot.com/





From caadams@motherboardzone.com  Fri Jun  6 14:36:18 2008
Return-Path: <caadams@motherboardzone.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 971803A6911;
	Fri,  6 Jun 2008 14:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -66.763
X-Spam-Level: 
X-Spam-Status: No, score=-66.763 tagged_above=-999 required=5
	tests=[BAYES_60=1, DNS_FROM_AHBL_RHSBL=0.692,
	FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994,
	FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395,
	J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5,
	RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
	RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 o3fwfsSVU7s6; Fri,  6 Jun 2008 14:36:18 -0700 (PDT)
Received: from 190-172-167-217.speedy.com.ar (unknown [190.172.167.217])
	by core3.amsl.com (Postfix) with SMTP id BC3843A680D;
	Fri,  6 Jun 2008 14:36:08 -0700 (PDT)
X-Originating-IP: 85.238.32.28 by smtp.190.172.167.217;  Fri, 06 Jun 2008 17:36:19 -0500
Message-ID: <rjsswvfVUGMDNtechspec@megatron.ietf.org>
From: "Keri Orr" <techspec@megatron.ietf.org>
Reply-To: "Keri Orr" <techspec@megatron.ietf.org>
To: techspec@megatron.ietf.org
Subject: New replica watches delivered fast
Date: Fri, 06 Jun 2008 17:36:19 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today!
http://doxeziwilyc31.blogspot.com/




From c.poulin@sphere-qc.ca  Fri Jun  6 20:11:26 2008
Return-Path: <c.poulin@sphere-qc.ca>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id F31A23A67F8;
	Fri,  6 Jun 2008 20:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -59.056
X-Spam-Level: 
X-Spam-Status: No, score=-59.056 tagged_above=-999 required=5
	tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994,
	GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5,
	RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
	RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666,
	SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062,
	SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 XKb6lc1ah2GA; Fri,  6 Jun 2008 20:11:25 -0700 (PDT)
Received: from 190-51-127-62.speedy.com.ar (unknown [190.51.127.62])
	by core3.amsl.com (Postfix) with SMTP id 44D253A67AA;
	Fri,  6 Jun 2008 20:11:20 -0700 (PDT)
X-Originating-IP: 134.72.223.48 by smtp.190.51.127.62;  Fri, 06 Jun 2008 23:11:31 -0500
Message-ID: <qwfzjENGUQAsmime-archive@megatron.ietf.org>
From: "Pauline Connell" <smime-archive@megatron.ietf.org>
Reply-To: "Pauline Connell" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Rolex replica is a ultimate gift
Date: Fri, 06 Jun 2008 23:11:31 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer!  With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica!
http://rusaxuhelop33.blogspot.com/






From cache@dowebs.com  Fri Jun  6 21:11:19 2008
Return-Path: <cache@dowebs.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8D1C53A6902;
	Fri,  6 Jun 2008 21:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -78.643
X-Spam-Level: 
X-Spam-Status: No, score=-78.643 tagged_above=-999 required=5
	tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451,
	HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129,
	RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877,
	RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TVD_RCVD_IP=1.931,
	USER_IN_WHITELIST=-100]
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 gVCVFqTQRMiE; Fri,  6 Jun 2008 21:11:18 -0700 (PDT)
Received: from 159-121-246-201.adsl.tie.cl (unknown [201.246.121.159])
	by core3.amsl.com (Postfix) with SMTP id 3F58C3A67D0;
	Fri,  6 Jun 2008 21:10:37 -0700 (PDT)
X-Originating-IP: 198.37.94.213 by smtp.201.246.121.159;  Sat, 07 Jun 2008 00:10:49 -0500
Message-ID: <svpqtgvTCVEKAQuser@ietf.org>
From: "Summer Hogan" <user@ietf.org>
Reply-To: "Summer Hogan" <user@ietf.org>
To: user@ietf.org
Subject: The affordable watch alternative
Date: Sat, 07 Jun 2008 00:10:49 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. 
http://pucyvegocin46.blogspot.com/

Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy!
http://pucyvegocin46.blogspot.com/






From c.laurenza@unipi-pasta.it  Fri Jun  6 21:56:32 2008
Return-Path: <c.laurenza@unipi-pasta.it>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6602C3A6833;
	Fri,  6 Jun 2008 21:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -83.617
X-Spam-Level: 
X-Spam-Status: No, score=-83.617 tagged_above=-999 required=5
	tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597,
	FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999,
	HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129,
	RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
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 Wvu36FhTxHGI; Fri,  6 Jun 2008 21:56:31 -0700 (PDT)
Received: from adsl190-28-128-60.epm.net.co (adsl190-28-128-60.epm.net.co [190.28.128.60])
	by core3.amsl.com (Postfix) with SMTP id 840673A63CB;
	Fri,  6 Jun 2008 21:56:23 -0700 (PDT)
X-Originating-IP: 169.21.254.104 by smtp.190.28.128.60;  Sat, 07 Jun 2008 00:56:35 -0500
Message-ID: <czjqybrCIOTVCtsv-area@ietf.org>
From: "Beverley Finch" <tsv-area@ietf.org>
Reply-To: "Beverley Finch" <tsv-area@ietf.org>
To: tsv-area@ietf.org
Subject: Inexpensive Louis Vuitton bags
Date: Sat, 07 Jun 2008 00:56:35 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece.
http://cururepilik28.blogspot.com/

Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience!
http://cururepilik28.blogspot.com/





No virus found in this outgoing message
Checked by PC Tools AntiVirus (4.0.0.26 - 10.076.013).
http://www.pctools.com/free-antivirus/


From owner-v6ops@ops.ietf.org  Sat Jun  7 01:11:05 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E0FC93A6929
	for <ietfarch-v6ops-archive@core3.amsl.com>; Sat,  7 Jun 2008 01:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.448
X-Spam-Level: 
X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_12=0.6,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 DDBUeg4YEm7H
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Sat,  7 Jun 2008 01:11:04 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C62623A69F5
	for <v6ops-archive@lists.ietf.org>; Sat,  7 Jun 2008 01:11:03 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K4tNI-0005Kn-Du
	for v6ops-data@psg.com; Sat, 07 Jun 2008 08:02:08 +0000
Received: from [193.1.169.34] (helo=dakota.ucd.ie)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <Niall.oReilly@ucd.ie>)
	id 1K4tN7-0005GN-90
	for v6ops@ops.ietf.org; Sat, 07 Jun 2008 08:02:03 +0000
Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie
 (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005))
 id <0K2300L01273QQ00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie)
 for v6ops@ops.ietf.org; Sat, 07 Jun 2008 09:01:55 +0100 (IST)
Received: from [10.0.1.189] ([83.141.81.52])
 by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28
 2005)) with ESMTPSA id <0K2300HOY2B6BHA0@dakota.ucd.ie>; Sat,
 07 Jun 2008 09:01:54 +0100 (IST)
Date: Sat, 07 Jun 2008 09:01:55 +0100
From: Niall O'Reilly <Niall.oReilly@ucd.ie>
Subject: Re: (Microsoft Windows DHCP Team Blog) : Use of extended length
 prefixes
In-reply-to: <0AC4B700F00DBB4C94F95727E09914140116FDC4@IMCSRV7.MITRE.ORG>
To: "Dunn, Jeffrey H." <jdunn@mitre.org>
Cc: Niall O'Reilly <Niall.oReilly@ucd.ie>, v6ops@ops.ietf.org
Message-id: <50F968C7-84E4-4F27-AE7E-031F6C1FA4E1@ucd.ie>
MIME-version: 1.0
X-Mailer: Apple Mail (2.753)
Content-type: multipart/signed; boundary=Apple-Mail-58-442797984;
 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-transfer-encoding: 7BIT
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
References: <0AC4B700F00DBB4C94F95727E09914140116FDC4@IMCSRV7.MITRE.ORG>
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


--Apple-Mail-58-442797984
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On 6 Jun 2008, at 12:42, Dunn, Jeffrey H. wrote:

> Many thanks to Ralph Droms for verifying that Cisco does support
> extended prefixes.

	YMMV.  Not all Cisco kit supports extended prefixes equally.


	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9




--Apple-Mail-58-442797984
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFISkB5eYfkja6ZXtkRAjAuAKCi8HYQ2W3OFSRIrAT8pJcwJw/IYACgnCR/
NoBgHpKjYYy0QazmpC72OvQ=
=LVFi
-----END PGP SIGNATURE-----

--Apple-Mail-58-442797984--



From cables@tones-n-things.com  Sun Jun  8 15:17:19 2008
Return-Path: <cables@tones-n-things.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 203183A6A92;
	Sun,  8 Jun 2008 15:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -57.012
X-Spam-Level: 
X-Spam-Status: No, score=-57.012 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994,
	HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129,
	RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033,
	RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062,
	TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 LA20h954PKKB; Sun,  8 Jun 2008 15:17:18 -0700 (PDT)
Received: from 131-130-22-190.adsl.terra.cl (131-130-22-190.adsl.terra.cl [190.22.130.131])
	by core3.amsl.com (Postfix) with SMTP id 5AD453A6844;
	Sun,  8 Jun 2008 15:17:14 -0700 (PDT)
X-Originating-IP: 76.68.235.44 by smtp.190.22.130.131;  Sun, 08 Jun 2008 18:17:39 -0500
Message-ID: <mqaqouDKISWYOsmime-archive@megatron.ietf.org>
From: "Hilary Duran" <smime-archive@megatron.ietf.org>
Reply-To: "Hilary Duran" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: The discreet replica store
Date: Sun, 08 Jun 2008 18:17:39 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal.
http://cygirapirer35.blogspot.com/

Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! 
http://cygirapirer35.blogspot.com/






From owner-v6ops@ops.ietf.org  Sun Jun  8 19:46:13 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D840C3A6885
	for <ietfarch-v6ops-archive@core3.amsl.com>; Sun,  8 Jun 2008 19:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.525
X-Spam-Level: 
X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5
	tests=[AWL=-1.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 VmICJp-kgsNv
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Sun,  8 Jun 2008 19:46:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id EB8713A6819
	for <v6ops-archive@lists.ietf.org>; Sun,  8 Jun 2008 19:46:10 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K5XG8-000JZE-NN
	for v6ops-data@psg.com; Mon, 09 Jun 2008 02:37:24 +0000
Received: from [209.85.146.177] (helo=wa-out-1112.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K5XG5-000JYe-44
	for v6ops@ops.ietf.org; Mon, 09 Jun 2008 02:37:22 +0000
Received: by wa-out-1112.google.com with SMTP id j37so1641977waf.23
        for <v6ops@ops.ietf.org>; Sun, 08 Jun 2008 19:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=h4rpGw7y4+A5n1NTlGZyxClIpr13IUEdqpesFxYEP/E=;
        b=tNdBA/L7OUp9KFGrAstaCEpa23nmKTeAau7FdW8OD+AS7jWI2m2jGO2WFVIoVk5SFf
         Yt5Gd+H0fS4xVE3NT7PXNfNWsayZqEDgXn4YmJPkiphQz+c4hgZoCpuVfFNn3Kp4b3nd
         29YyZmjI9XKYtDd0E3Wg/CQ/rPLHUwM5PDq30=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=JPeUy1BzfFSYL2XbG2bpK3frYA6zodxnuSFaVwILOv29WJNpChPpdrDa3S2SszfgkU
         NjRiepxelpVcDgbquqTfSKet2JEmwrkKsXrlgMsLzyLb5A/e4WVZMMQfz0N53Z/JZ3qE
         AuX7lm/2SrfHHeqobhOUBhbhrIoKC6WmtDpgQ=
Received: by 10.114.161.11 with SMTP id j11mr2698637wae.105.1212979038776;
        Sun, 08 Jun 2008 19:37:18 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id n30sm11876009wag.13.2008.06.08.19.37.16
        (version=SSLv3 cipher=RC4-MD5);
        Sun, 08 Jun 2008 19:37:17 -0700 (PDT)
Message-ID: <484C9758.90904@gmail.com>
Date: Mon, 09 Jun 2008 14:37:12 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
References: <20080513233001.301873A6854@core3.amsl.com>
In-Reply-To: <20080513233001.301873A6854@core3.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi,

A few comments:

> 2.1.  Transition scenarios
> 
>    There are six obvious transition scenarios:

I think we can avoid off-topic reactions by changing this
slightly:

   There are six obvious IP layer transition scenarios:

and adding underneath something like

   Transition scenarios involving the use of upper layer proxies
   have their place, but are out of scope for this document.

> 2.1.3.  Transition scenarios that require translation

I think there's a point that should be made in this section:

In practice, it is highly likely that addresses will be in short
supply in the IPv4-only domain, and therefore that address sharing
and port mapping will be required. These functions may or may not
be combined with the IPv6-IPv4 translation function.

> 3.3.  v4 addressing consideration
...
>    ...The case where the v4-only node has a
>    private v4 address and the NAT64 box has a public address seems also
>    possible, but here it seems reasonable to assume that a NAT box will
>    exist between the v4 only node and the NAT64 box.  

There is an alternative assumption which is that traditional NAT
(v4 to v4) is embedded in the NAT64 device. There is a difference,
because then the NAT64 is aware of the address and port mappings
(and that opens some possibilities, as SHANTI and MNAT-PT show).

> 3.4.  Name-space considerations
> 
>    One of the major choices that are faced when designing a NAT4
>    mechanism that enable communication initiated by the v4-only node
>    towards a v6-only node.  In this case, the v4 only node needs to
>    identify the v6 only node and the problem is that there is no means
>    to permanently map the v6 address space in the v4 address space.  

Well yes, that is unsolvable, so let's not try to solve it.
This returns to point about port mapping - if you want the NAT64 to
support incoming sessions, the number of sessions is limited by
(number of ports)*(number of IPv4 addresses). In DNS, the IPv6-only
servers will have to be represented by a shared A record for each
IPv4 address. That doesn't require a DNS ALG. But it does require
defined mappings for inbound ports. That's NAT 101, and the mapping
to IPv6 doesn't change it.

>    o  R2.2: Translation mechanim must support v4-initiated short-lived
>       local handle (as defined in Section 3.1). (not clear if there is
>       consensus for this)

I think that if we're going to do this at all, it needs to be symmetrical,
so I hum for this.

>    o  R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4
>       private addresses and use a NAT.(The acceptance of R2.2.1 is
>       subject to the acceptance of R2.2.

As noted above, that does *not* imply a separate NAT; it could be combined
with the NAT64.

  Brian



From owner-v6ops@ops.ietf.org  Sun Jun  8 19:50:55 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6878B3A6901
	for <ietfarch-v6ops-archive@core3.amsl.com>; Sun,  8 Jun 2008 19:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.434
X-Spam-Level: 
X-Spam-Status: No, score=-5.434 tagged_above=-999 required=5
	tests=[AWL=-0.939, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 ZKjWw4umhAdk
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Sun,  8 Jun 2008 19:50:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id E376A3A67A1
	for <v6ops-archive@lists.ietf.org>; Sun,  8 Jun 2008 19:50:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K5XSN-000Lhb-QM
	for v6ops-data@psg.com; Mon, 09 Jun 2008 02:50:03 +0000
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.69 (FreeBSD))
	(envelope-from <gvandeve@cisco.com>)
	id 1K5XSB-000LfB-CO
	for v6ops@ops.ietf.org; Mon, 09 Jun 2008 02:50:01 +0000
X-IronPort-AV: E=Sophos;i="4.27,610,1204498800"; 
   d="scan'208";a="11079548"
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
  by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 04:49:35 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m592nZEI001546
	for <v6ops@ops.ietf.org>; Mon, 9 Jun 2008 04:49:35 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71])
	by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m592nZMP007512
	for <v6ops@ops.ietf.org>; Mon, 9 Jun 2008 02:49:35 GMT
Received: from xmb-ams-33c.emea.cisco.com ([144.254.231.91]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 9 Jun 2008 04:49:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject:  draft-ietf-v6ops-addcon 
Date: Mon, 9 Jun 2008 04:49:34 +0200
Message-ID: <70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
In-Reply-To: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  draft-ietf-v6ops-addcon 
Thread-Index: Aci8EWg13T4769rKR6e1RrQoNG6xeQKGOgBgACrNn5AAAq6zIABEYZTg
References: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>,
        <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 09 Jun 2008 02:49:34.0959 (UTC) FILETIME=[734E47F0:01C8C9DB]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3551; t=1212979775; x=1213843775;
	c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gvandeve@cisco.com;
	z=From:=20=22Gunter=20Van=20de=20Velde=20(gvandeve)=22=20<gv
	andeve@cisco.com>
	|Subject:=20=20draft-ietf-v6ops-addcon=20
	|Sender:=20;
	bh=jmYGPzjFoh9BKPCd5MwRpAe8ysUG4Tuu5YfcUQtuaGw=;
	b=u634HPECsDHLDonDA45/urHJVE1VJXCA8AU/RaFtSxu9SYtTJZYmMvtaOu
	K+Q815KyOEVd6NwF9hlt/eN6EOdZjje5AwlqE+2jklEgjIYNpWFUeI+94nXb
	pLqoy6onZu;
Authentication-Results: ams-dkim-2; header.From=gvandeve@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim2001 verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Folks,

The question here is if different then /64 prefix considerations should
be given?

At the moment any prefix NOT starting with '000' must have a 64bit
network ID.
The addcon draft documents items that 'if' one has to divert from this=20
recommendation (against any IETF doc) to at least be aware of other=20
restrictions regarding anycast, etc....

Now at IESG review that is contested, and the editors are trying to=20
understand if sections 3.1 (larger then /64) and 3.3 (smaller then /64)
should=20
be removed or not?

I think it is good content as reality seems to indicate that people DO
use=20
different then /64 prefix addresses.

Any thoughts? Flames? Screams?

G/

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Gunter Van de Velde (gvandeve)
Sent: Thursday, June 05, 2008 9:51 AM
To: v6ops@ops.ietf.org
Subject: FW: DISCUSS: draft-ietf-v6ops-addcon=20

Hi All,

During IESG review an interresting comment appeared regarding different
then /64 addresses and would like to understand if the WG has some
opinion before 'removing' section 3.1 and 3.3.

See context of the Comment below.

Brgds,
G/

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: Thursday, June 05, 2008 8:53 AM
To: Gunter Van de Velde (gvandeve); iesg@ietf.org
Cc: v6ops-chairs@tools.ietf.org; draft-ietf-v6ops-addcon@tools.ietf.org
Subject: RE: DISCUSS: draft-ietf-v6ops-addcon=20

Hi Gunter,=20

> GV> Maybe an extra sentence should be added here to make this crystal=20
> GV> clear? What about the following:
>=20
> GV> CHANGED TO:
> GV> Based on RFC4291 it is legal for any IPv6 unicast address starting

> GV> with binary address '000' to have a subnet prefix larger than,=20
> GV> smaller than or equal to 64 bits. Each of these three options is=20
> GV> discussed in this document. This document mainly considers global=20
> GV> addresses (assigned from RIR/LIR) and ULAs and while neither of=20
> GV> these address types start with binary "000"
> GV> only /64 prefixes are allowed on these types of addresses.
>=20
> GV> Is the above an acceptable solution?=20

If Sections 3.1 and 3.3 do not apply to global addresses or ULAs, what
addresses they do apply to?

(In particular, the discussion doesn't seem relevant for IPv4-Compatible
or IPv4-Mapped Addresses, and clearly isn't about the Unspecified or the
Loopback Address. And this kind of detailed advice doesn't seem
appropriate for some future, not-yet-defined addresses, whose properties
we don't really know yet.)

If the intent is simply to describe how to use prefixes other than
/64 with global addresses -- which I know some folks are doing -- then
this document needs have "Updates: RFC 4291" on cover page, and be
explicit about changing the "MUST" in RFC 4291. (And obviously, there
needs to be rough IETF consensus to make this change.)

> Section 6 should say that using subnet prefixes other than /64 breaks=20
> security mechanisms such as Cryptographically Generated Addresses
> (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible=20
> to use protocols that depend on them.
>=20
> GV> It is indicated in Section 3. that these mechanisms are broken.=20

The text that was added to Section 3 does not mention CGAs or HBAs.
Also, it should be in Section 6, as the current text there ("This
document doesn't add any new security considerations...") is incorrect.

Best regards,
Pasi




From owner-v6ops@ops.ietf.org  Sun Jun  8 21:38:37 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6345D3A68A0
	for <ietfarch-v6ops-archive@core3.amsl.com>; Sun,  8 Jun 2008 21:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level: 
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 VXAs-wicALhQ
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Sun,  8 Jun 2008 21:38:36 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 1D3933A68AD
	for <v6ops-archive@lists.ietf.org>; Sun,  8 Jun 2008 21:38:36 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K5Z5v-000ECf-GH
	for v6ops-data@psg.com; Mon, 09 Jun 2008 04:34:59 +0000
Received: from [207.219.45.62] (helo=mx4.ca.afilias.info)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <briand@ca.afilias.info>)
	id 1K5Z5r-000EC5-6W
	for v6ops@ops.ietf.org; Mon, 09 Jun 2008 04:34:57 +0000
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90])
	by mx4.ca.afilias.info with esmtp (Exim 4.22)
	id 1K5Z5q-000053-DQ; Mon, 09 Jun 2008 00:34:54 -0400
Message-ID: <484CB2E9.2010008@ca.afilias.info>
Date: Mon, 09 Jun 2008 00:34:49 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
CC: v6ops@ops.ietf.org
Subject: Re: draft-ietf-v6ops-addcon
References: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com> <70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
In-Reply-To: <70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Gunter Van de Velde (gvandeve) wrote:
> Folks,
>
> The question here is if different then /64 prefix considerations should
> be given?
>
> At the moment any prefix NOT starting with '000' must have a 64bit
> network ID.
> The addcon draft documents items that 'if' one has to divert from this 
> recommendation (against any IETF doc) to at least be aware of other 
> restrictions regarding anycast, etc....
>
> Now at IESG review that is contested, and the editors are trying to 
> understand if sections 3.1 (larger then /64) and 3.3 (smaller then /64)
> should 
> be removed or not?
>
> I think it is good content as reality seems to indicate that people DO
> use 
> different then /64 prefix addresses.
>
> Any thoughts? Flames? Screams?
>
>   

I have several comments regarding both this draft, and how it interacts 
with other RFCs.

Bottom line is, I am in favour of KEEPING the 3.1 and 3.3 sections.

Here's my comments:

Basically, sticking to the notion that only /N where N=64 can be used 
for a prefix length, ignores reality.

Yes, there are people (and networks, some very large) using lots of 
other values of  N, and it benefits the wider
community to document "things that break", "things that work", and such, 
when using N != 64.

IMHO, if there is incompatibility on the part of HBA or CGAs, the defect 
is in the RFCs describing those.
There is nothing *strictly* required for N=64 in the general case for 
CGAs or HBA. The hard-coding of 64 bits
in those RFCs was, IMNSHO, a serious error, placing limitations on its 
use for all cases N != 64.

(Implementations of those RFCs, and those RFCs themselves, would do well 
to add flexibility on values of N.
Yes, it is true, that N=60 may in some sense be slightly weaker than 
N=64. However, if the underlying crypto uses
128 bits in its randomization, which I believe is the case, then exactly 
which N of those bits get used doesn't actually
weaken the predictability. Brute force attacks on crypto only  work 
where the crypto base is small, not where the bits
used from the result of the crypto are small.)

Having actually looked at code for various IPv6 things in popular 
implementations (linux, freebsd, etc.), most of the
places where N=64 is verified, does so by checking N=64 and throwing an 
error. In most cases, if that check were removed,
the code will continue to handle the general case just fine, and the sky 
won't fall.

I agree that placing references to RFCs that have N=64 as prerequisites, 
would be helpful in understanding the impact
of using N != 64.

Brian Dickson

> G/
>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Gunter Van de Velde (gvandeve)
> Sent: Thursday, June 05, 2008 9:51 AM
> To: v6ops@ops.ietf.org
> Subject: FW: DISCUSS: draft-ietf-v6ops-addcon 
>
> Hi All,
>
> During IESG review an interresting comment appeared regarding different
> then /64 addresses and would like to understand if the WG has some
> opinion before 'removing' section 3.1 and 3.3.
>
> See context of the Comment below.
>
> Brgds,
> G/
>
> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> Sent: Thursday, June 05, 2008 8:53 AM
> To: Gunter Van de Velde (gvandeve); iesg@ietf.org
> Cc: v6ops-chairs@tools.ietf.org; draft-ietf-v6ops-addcon@tools.ietf.org
> Subject: RE: DISCUSS: draft-ietf-v6ops-addcon 
>
> Hi Gunter, 
>
>   
>> GV> Maybe an extra sentence should be added here to make this crystal 
>> GV> clear? What about the following:
>>
>> GV> CHANGED TO:
>> GV> Based on RFC4291 it is legal for any IPv6 unicast address starting
>>     
>
>   
>> GV> with binary address '000' to have a subnet prefix larger than, 
>> GV> smaller than or equal to 64 bits. Each of these three options is 
>> GV> discussed in this document. This document mainly considers global 
>> GV> addresses (assigned from RIR/LIR) and ULAs and while neither of 
>> GV> these address types start with binary "000"
>> GV> only /64 prefixes are allowed on these types of addresses.
>>
>> GV> Is the above an acceptable solution? 
>>     
>
> If Sections 3.1 and 3.3 do not apply to global addresses or ULAs, what
> addresses they do apply to?
>
> (In particular, the discussion doesn't seem relevant for IPv4-Compatible
> or IPv4-Mapped Addresses, and clearly isn't about the Unspecified or the
> Loopback Address. And this kind of detailed advice doesn't seem
> appropriate for some future, not-yet-defined addresses, whose properties
> we don't really know yet.)
>
> If the intent is simply to describe how to use prefixes other than
> /64 with global addresses -- which I know some folks are doing -- then
> this document needs have "Updates: RFC 4291" on cover page, and be
> explicit about changing the "MUST" in RFC 4291. (And obviously, there
> needs to be rough IETF consensus to make this change.)
>
>   
>> Section 6 should say that using subnet prefixes other than /64 breaks 
>> security mechanisms such as Cryptographically Generated Addresses
>> (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible 
>> to use protocols that depend on them.
>>
>> GV> It is indicated in Section 3. that these mechanisms are broken. 
>>     
>
> The text that was added to Section 3 does not mention CGAs or HBAs.
> Also, it should be in Section 6, as the current text there ("This
> document doesn't add any new security considerations...") is incorrect.
>
> Best regards,
> Pasi
>
>
>   




From owner-v6ops@ops.ietf.org  Sun Jun  8 22:06:51 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 557193A6A7B
	for <ietfarch-v6ops-archive@core3.amsl.com>; Sun,  8 Jun 2008 22:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level: 
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5
	tests=[AWL=-0.612, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_EQ_AU=0.377, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1,
	RELAY_IS_203=0.994]
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 nqZcMsJuECdw
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Sun,  8 Jun 2008 22:06:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 433C53A6A0D
	for <v6ops-archive@lists.ietf.org>; Sun,  8 Jun 2008 22:06:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K5ZYt-000JYH-AN
	for v6ops-data@psg.com; Mon, 09 Jun 2008 05:04:55 +0000
Received: from [203.6.132.75] (helo=smtp1.mail.adnap.net.au)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>)
	id 1K5ZYo-000JXT-Le
	for v6ops@ops.ietf.org; Mon, 09 Jun 2008 05:04:53 +0000
Received: from 122-49-134-106.ip.adam.com.au ([122.49.134.106] helo=mail.nosense.org)
	by smtp1.mail.adnap.net.au with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>)
	id 1K5ZYi-000ADA-Cz; Mon, 09 Jun 2008 14:34:44 +0930
Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1])
	by mail.nosense.org (Postfix) with SMTP id 58D7A11E7F;
	Mon,  9 Jun 2008 14:34:43 +0930 (CST)
Date: Mon, 9 Jun 2008 14:34:42 +0930
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Cc: <v6ops@ops.ietf.org>
Subject: Re: draft-ietf-v6ops-addcon
Message-Id: <20080609143442.7daf279d.ipng@69706e6720323030352d30312d31340a.nosense.org>
In-Reply-To: <70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
References: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com>
	<70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i686-pc-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi Gunter,

On Mon, 9 Jun 2008 04:49:34 +0200
"Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> wrote:

> Folks,
> 
> The question here is if different then /64 prefix considerations should
> be given?
> 
> At the moment any prefix NOT starting with '000' must have a 64bit
> network ID.
> The addcon draft documents items that 'if' one has to divert from this 
> recommendation (against any IETF doc) to at least be aware of other 
> restrictions regarding anycast, etc....
> 
> Now at IESG review that is contested, and the editors are trying to 
> understand if sections 3.1 (larger then /64) and 3.3 (smaller then /64)
> should 
> be removed or not?
> 
> I think it is good content as reality seems to indicate that people DO
> use 
> different then /64 prefix addresses.
> 
> Any thoughts? Flames? Screams?
> 

I think there is value keeping it in there. If IPv6 will work with
longer than /64 prefixes in certain cases (e.g. when not using CGAs,
etc.), I think there's value in advising people of what issues they'll
encounter or need to avoid, should they choose not to stick to /64s.
Choosing whether to have non-/64s, contrary to the RFCs, seems to me to
be very much an Addressing Consideration.

Regards,
Mark.

> G/
> 
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Gunter Van de Velde (gvandeve)
> Sent: Thursday, June 05, 2008 9:51 AM
> To: v6ops@ops.ietf.org
> Subject: FW: DISCUSS: draft-ietf-v6ops-addcon 
> 
> Hi All,
> 
> During IESG review an interresting comment appeared regarding different
> then /64 addresses and would like to understand if the WG has some
> opinion before 'removing' section 3.1 and 3.3.
> 
> See context of the Comment below.
> 
> Brgds,
> G/
> 
> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> Sent: Thursday, June 05, 2008 8:53 AM
> To: Gunter Van de Velde (gvandeve); iesg@ietf.org
> Cc: v6ops-chairs@tools.ietf.org; draft-ietf-v6ops-addcon@tools.ietf.org
> Subject: RE: DISCUSS: draft-ietf-v6ops-addcon 
> 
> Hi Gunter, 
> 
> > GV> Maybe an extra sentence should be added here to make this crystal 
> > GV> clear? What about the following:
> > 
> > GV> CHANGED TO:
> > GV> Based on RFC4291 it is legal for any IPv6 unicast address starting
> 
> > GV> with binary address '000' to have a subnet prefix larger than, 
> > GV> smaller than or equal to 64 bits. Each of these three options is 
> > GV> discussed in this document. This document mainly considers global 
> > GV> addresses (assigned from RIR/LIR) and ULAs and while neither of 
> > GV> these address types start with binary "000"
> > GV> only /64 prefixes are allowed on these types of addresses.
> > 
> > GV> Is the above an acceptable solution? 
> 
> If Sections 3.1 and 3.3 do not apply to global addresses or ULAs, what
> addresses they do apply to?
> 
> (In particular, the discussion doesn't seem relevant for IPv4-Compatible
> or IPv4-Mapped Addresses, and clearly isn't about the Unspecified or the
> Loopback Address. And this kind of detailed advice doesn't seem
> appropriate for some future, not-yet-defined addresses, whose properties
> we don't really know yet.)
> 
> If the intent is simply to describe how to use prefixes other than
> /64 with global addresses -- which I know some folks are doing -- then
> this document needs have "Updates: RFC 4291" on cover page, and be
> explicit about changing the "MUST" in RFC 4291. (And obviously, there
> needs to be rough IETF consensus to make this change.)
> 
> > Section 6 should say that using subnet prefixes other than /64 breaks 
> > security mechanisms such as Cryptographically Generated Addresses
> > (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible 
> > to use protocols that depend on them.
> > 
> > GV> It is indicated in Section 3. that these mechanisms are broken. 
> 
> The text that was added to Section 3 does not mention CGAs or HBAs.
> Also, it should be in Section 6, as the current text there ("This
> document doesn't add any new security considerations...") is incorrect.
> 
> Best regards,
> Pasi
> 
> 



From c.herbert@atelier-dusty.de  Mon Jun  9 00:51:29 2008
Return-Path: <c.herbert@atelier-dusty.de>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2B7CC3A688E;
	Mon,  9 Jun 2008 00:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -47.382
X-Spam-Level: 
X-Spam-Status: No, score=-47.382 tagged_above=-999 required=5
	tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994,
	FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395,
	RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033,
	RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666,
	SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062,
	SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666,
	TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 z7bu4NgdaLvC; Mon,  9 Jun 2008 00:51:28 -0700 (PDT)
Received: from 19-115-188-190.cab.prima.net.ar (unknown [190.188.115.19])
	by core3.amsl.com (Postfix) with SMTP id C4A033A689E;
	Mon,  9 Jun 2008 00:51:18 -0700 (PDT)
X-Originating-IP: 129.61.219.184 by smtp.190.188.115.19;  Mon, 09 Jun 2008 03:51:44 -0500
Message-ID: <afhilUVPTOsmime-archive@megatron.ietf.org>
From: "Robbie Rivers" <smime-archive@megatron.ietf.org>
Reply-To: "Robbie Rivers" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Replica watches made easy
Date: Mon, 09 Jun 2008 03:51:44 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers.
http://voceceliguv46.blogspot.com/

Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal!
http://voceceliguv46.blogspot.com/





From cabins@laurel-mountain-cabins.com  Mon Jun  9 08:11:01 2008
Return-Path: <cabins@laurel-mountain-cabins.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8C3FE3A69AA;
	Mon,  9 Jun 2008 08:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -63.752
X-Spam-Level: 
X-Spam-Status: No, score=-63.752 tagged_above=-999 required=5
	tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295,
	HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129,
	HOST_EQ_DIALUP=0.862, RAZOR2_CF_RANGE_51_100=0.5,
	RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
	RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666,
	SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100]
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 HFOM2m9Fgx5L; Mon,  9 Jun 2008 08:11:00 -0700 (PDT)
Received: from r190-134-130-109.dialup.adsl.anteldata.net.uy (r190-134-130-109.dialup.adsl.anteldata.net.uy [190.134.130.109])
	by core3.amsl.com (Postfix) with SMTP id 921EC28C15F;
	Mon,  9 Jun 2008 08:10:53 -0700 (PDT)
X-Originating-IP: 144.52.181.48 by smtp.190.134.130.109;  Mon, 09 Jun 2008 11:11:19 -0500
Message-ID: <goyzfNFUXDsmime-archive@megatron.ietf.org>
From: "Allyson Hanna" <smime-archive@megatron.ietf.org>
Reply-To: "Allyson Hanna" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Trim line or sport watch? You choose
Date: Mon, 09 Jun 2008 11:11:19 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer!  With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica!
http://wafehyrybob84.blogspot.com/






From owner-v6ops@ops.ietf.org  Mon Jun  9 14:08:36 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 87DB83A6C2F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon,  9 Jun 2008 14:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.424
X-Spam-Level: 
X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5
	tests=[AWL=-0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 f2xsdR2iIMEu
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon,  9 Jun 2008 14:08:35 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 6CF713A67C0
	for <v6ops-archive@lists.ietf.org>; Mon,  9 Jun 2008 14:08:31 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K5oVb-000PoJ-T9
	for v6ops-data@psg.com; Mon, 09 Jun 2008 21:02:31 +0000
Received: from [209.85.146.179] (helo=wa-out-1112.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K5oVY-000Pnn-2A
	for v6ops@ops.ietf.org; Mon, 09 Jun 2008 21:02:29 +0000
Received: by wa-out-1112.google.com with SMTP id j37so1921295waf.23
        for <v6ops@ops.ietf.org>; Mon, 09 Jun 2008 14:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=TPecqjj/ZPeqTPd645gGMNiCjVlFMZ7JSXlW0dryP3o=;
        b=Zms0XzwbYAWQeAVP7ditvVBj+iWwtU3dedb4JyvutjCytpxaZitAp318o6WgY4JjeU
         42jvuE023351c7kwnolfU1z/AaRDW1nRKlxTnCzcSWkO5C94aS4mnCw/6z+8XttSh7yJ
         RyyNIav1TzMZZE+xpqL6gYcs8P122Pr4n5Ad4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=rGCK7kE2rDk8Tgc244jeXB7u91ZLwW8VvaFcW9Ekz0KAvc0YXVjX5co9lRVsP6Rlxh
         j75mn18YsnSV55bDp8W+5At2V/iKnKS0w/frKx8CA1ej0vmX0vycXFrUERRWdOKXd3rl
         gQFxBOcarVwdfGBipXd+9Degi20HCV9JXFcdE=
Received: by 10.114.194.1 with SMTP id r1mr4003082waf.205.1213045313608;
        Mon, 09 Jun 2008 14:01:53 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id j38sm17305965waf.56.2008.06.09.14.01.51
        (version=SSLv3 cipher=RC4-MD5);
        Mon, 09 Jun 2008 14:01:53 -0700 (PDT)
Message-ID: <484D9A3D.2030104@gmail.com>
Date: Tue, 10 Jun 2008 09:01:49 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
CC: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>, 
 v6ops@ops.ietf.org
Subject: Re: draft-ietf-v6ops-addcon
References: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com>	<70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com> <20080609143442.7daf279d.ipng@69706e6720323030352d30312d31340a.nosense.org>
In-Reply-To: <20080609143442.7daf279d.ipng@69706e6720323030352d30312d31340a.nosense.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 2008-06-09 17:04, Mark Smith wrote:
> Hi Gunter,
> 
> On Mon, 9 Jun 2008 04:49:34 +0200
> "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> wrote:
> 
>> Folks,
>>
>> The question here is if different then /64 prefix considerations should
>> be given?
>>
>> At the moment any prefix NOT starting with '000' must have a 64bit
>> network ID.
>> The addcon draft documents items that 'if' one has to divert from this 
>> recommendation (against any IETF doc) to at least be aware of other 
>> restrictions regarding anycast, etc....
>>
>> Now at IESG review that is contested, and the editors are trying to 
>> understand if sections 3.1 (larger then /64) and 3.3 (smaller then /64)
>> should 
>> be removed or not?
>>
>> I think it is good content as reality seems to indicate that people DO
>> use 
>> different then /64 prefix addresses.
>>
>> Any thoughts? Flames? Screams?
>>
> 
> I think there is value keeping it in there. If IPv6 will work with
> longer than /64 prefixes in certain cases (e.g. when not using CGAs,
> etc.), I think there's value in advising people of what issues they'll
> encounter or need to avoid, should they choose not to stick to /64s.
> Choosing whether to have non-/64s, contrary to the RFCs, seems to me to
> be very much an Addressing Consideration.

I agree. This is an Informational document so it should contain all
relevant information. It might be worth being extra clear that
this is not recommended practice, but since there are phrases like
"An allocation of a prefix shorter then 64 bits to a node or interface
is considered bad practice." and
"this kind of address conservation is of little benefit ..."
seem pretty clear to me.

    Brian
> 
> Regards,
> Mark.
> 
>> G/
>>
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
>> Behalf Of Gunter Van de Velde (gvandeve)
>> Sent: Thursday, June 05, 2008 9:51 AM
>> To: v6ops@ops.ietf.org
>> Subject: FW: DISCUSS: draft-ietf-v6ops-addcon 
>>
>> Hi All,
>>
>> During IESG review an interresting comment appeared regarding different
>> then /64 addresses and would like to understand if the WG has some
>> opinion before 'removing' section 3.1 and 3.3.
>>
>> See context of the Comment below.
>>
>> Brgds,
>> G/
>>
>> -----Original Message-----
>> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
>> Sent: Thursday, June 05, 2008 8:53 AM
>> To: Gunter Van de Velde (gvandeve); iesg@ietf.org
>> Cc: v6ops-chairs@tools.ietf.org; draft-ietf-v6ops-addcon@tools.ietf.org
>> Subject: RE: DISCUSS: draft-ietf-v6ops-addcon 
>>
>> Hi Gunter, 
>>
>>> GV> Maybe an extra sentence should be added here to make this crystal 
>>> GV> clear? What about the following:
>>>
>>> GV> CHANGED TO:
>>> GV> Based on RFC4291 it is legal for any IPv6 unicast address starting
>>> GV> with binary address '000' to have a subnet prefix larger than, 
>>> GV> smaller than or equal to 64 bits. Each of these three options is 
>>> GV> discussed in this document. This document mainly considers global 
>>> GV> addresses (assigned from RIR/LIR) and ULAs and while neither of 
>>> GV> these address types start with binary "000"
>>> GV> only /64 prefixes are allowed on these types of addresses.
>>>
>>> GV> Is the above an acceptable solution? 
>> If Sections 3.1 and 3.3 do not apply to global addresses or ULAs, what
>> addresses they do apply to?
>>
>> (In particular, the discussion doesn't seem relevant for IPv4-Compatible
>> or IPv4-Mapped Addresses, and clearly isn't about the Unspecified or the
>> Loopback Address. And this kind of detailed advice doesn't seem
>> appropriate for some future, not-yet-defined addresses, whose properties
>> we don't really know yet.)
>>
>> If the intent is simply to describe how to use prefixes other than
>> /64 with global addresses -- which I know some folks are doing -- then
>> this document needs have "Updates: RFC 4291" on cover page, and be
>> explicit about changing the "MUST" in RFC 4291. (And obviously, there
>> needs to be rough IETF consensus to make this change.)
>>
>>> Section 6 should say that using subnet prefixes other than /64 breaks 
>>> security mechanisms such as Cryptographically Generated Addresses
>>> (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible 
>>> to use protocols that depend on them.
>>>
>>> GV> It is indicated in Section 3. that these mechanisms are broken. 
>> The text that was added to Section 3 does not mention CGAs or HBAs.
>> Also, it should be in Section 6, as the current text there ("This
>> document doesn't add any new security considerations...") is incorrect.
>>
>> Best regards,
>> Pasi
>>
>>
> 
> 



From cabinet@brevesud.com  Mon Jun  9 14:40:36 2008
Return-Path: <cabinet@brevesud.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 89ED23A67AD;
	Mon,  9 Jun 2008 14:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -83.338
X-Spam-Level: 
X-Spam-Status: No, score=-83.338 tagged_above=-999 required=5
	tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398,
	HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979,
	RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033,
	RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
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 sm60npcyocmI; Mon,  9 Jun 2008 14:40:35 -0700 (PDT)
Received: from cpe-76-171-100-69.socal.res.rr.com (cpe-76-171-100-69.socal.res.rr.com [76.171.100.69])
	by core3.amsl.com (Postfix) with SMTP id C2FD53A67EF;
	Mon,  9 Jun 2008 14:39:43 -0700 (PDT)
X-Originating-IP: 170.148.48.204 by smtp.76.171.100.69;  Mon, 09 Jun 2008 17:40:01 -0500
Message-ID: <gfufboJFEVXtsv-area@ietf.org>
From: "Hollie Ayers" <tsv-area@ietf.org>
Reply-To: "Hollie Ayers" <tsv-area@ietf.org>
To: tsv-area@ietf.org
Subject: 15% off on two watches
Date: Mon, 09 Jun 2008 17:40:01 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. 
http://pitanigixad34.blogspot.com/

Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy!
http://pitanigixad34.blogspot.com/






From c.sthilaire@maindanslamain.org  Mon Jun  9 16:13:08 2008
Return-Path: <c.sthilaire@maindanslamain.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 173BD3A68C1;
	Mon,  9 Jun 2008 16:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -80.264
X-Spam-Level: 
X-Spam-Status: No, score=-80.264 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597,
	FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994,
	HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877,
	RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666,
	USER_IN_WHITELIST=-100]
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 rlfT4hPxjS9B; Mon,  9 Jun 2008 16:13:07 -0700 (PDT)
Received: from pc-188-127-86-200.cm.vtr.net (pc-188-127-86-200.cm.vtr.net [200.86.127.188])
	by core3.amsl.com (Postfix) with SMTP id AD0AA3A67D4;
	Mon,  9 Jun 2008 16:12:49 -0700 (PDT)
X-Originating-IP: 139.20.91.24 by smtp.200.86.127.188;  Mon, 09 Jun 2008 19:13:15 -0500
Message-ID: <pmlgkauIKWKQsmime-archive@megatron.ietf.org>
From: "Micheal Blue" <smime-archive@megatron.ietf.org>
Reply-To: "Micheal Blue" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: The discreet replica store
Date: Mon, 09 Jun 2008 19:13:15 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://gyzywarezax23.blogspot.com/  For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas.
http://gyzywarezax23.blogspot.com/





From owner-v6ops@ops.ietf.org  Tue Jun 10 02:34:21 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 12C543A6AD8
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 10 Jun 2008 02:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.75
X-Spam-Level: 
X-Spam-Status: No, score=0.75 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35,
	HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1]
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 lDvwyfjl0ywH
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 10 Jun 2008 02:34:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id B60A128C0E5
	for <v6ops-archive@lists.ietf.org>; Tue, 10 Jun 2008 02:33:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K606f-0001qc-RZ
	for v6ops-data@psg.com; Tue, 10 Jun 2008 09:25:33 +0000
Received: from [134.76.10.26] (helo=mailer.gwdg.de)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K606U-0001oz-2k
	for v6ops@ops.ietf.org; Tue, 10 Jun 2008 09:25:31 +0000
Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5])
	by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69)
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K606I-0003HM-33
	for v6ops@ops.ietf.org; Tue, 10 Jun 2008 11:25:10 +0200
Message-ID: <484E4875.1040508@cs.uni-goettingen.de>
Date: Tue, 10 Jun 2008 11:25:09 +0200
From: Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Organization: University of Goettingen
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: v6ops@ops.ietf.org
Subject: Router Solicitations
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: (clean) by exiscan+sophie
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hello everybody,

I have a question regarding RFC 4861, Section 6.3.7. "Sending Router 
Solicitations". The RFC states that when a host is sending a Router 
Solicitation, "the IP source address is set to either one of the 
interface's unicast addresses or the unspecified address."

So my question is
1) when is a host supposed to set a unicast address and
2) what qualifies as "one of the interface's unicast addresses?"

For example: Is an implementation supposed to remember the last address 
an interface had and to include this address in a Router Solicitation 
after the host attaches to a new link?


Thanks in advance and best regards
   Niklas

-- 
Niklas Neumann - University of Goettingen, Institute of Informatics
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-14419



From cacqaaaaaenaxnwq@wegnohotone.b.tep1.com  Tue Jun 10 04:35:53 2008
Return-Path: <cacqaaaaaenaxnwq@wegnohotone.b.tep1.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E269428C191;
	Tue, 10 Jun 2008 04:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -74.32
X-Spam-Level: 
X-Spam-Status: No, score=-74.32 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357,
	FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245,
	RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062,
	USER_IN_WHITELIST=-100]
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 AmBFuguvaHxX; Tue, 10 Jun 2008 04:35:53 -0700 (PDT)
Received: from ppp-42-170.32-151.iol.it (ppp-42-170.32-151.iol.it [151.32.170.42])
	by core3.amsl.com (Postfix) with SMTP id 21CD428C165;
	Tue, 10 Jun 2008 04:35:43 -0700 (PDT)
X-Originating-IP: 194.119.4.95 by smtp.151.32.170.42;  Tue, 10 Jun 2008 07:36:07 -0500
Message-ID: <pakhjqVATGMUtechspec@megatron.ietf.org>
From: "Willie Barrera" <techspec@megatron.ietf.org>
Reply-To: "Willie Barrera" <techspec@megatron.ietf.org>
To: techspec@megatron.ietf.org
Subject: Impressive Glashutte timepieces
Date: Tue, 10 Jun 2008 07:36:07 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal.
http://bamyrypasyx48.blogspot.com/

Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! 
http://bamyrypasyx48.blogspot.com/





From cabincreek@cabincreekdesigns.com  Tue Jun 10 10:08:33 2008
Return-Path: <cabincreek@cabincreekdesigns.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0F1DA3A6856;
	Tue, 10 Jun 2008 10:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -68.932
X-Spam-Level: 
X-Spam-Status: No, score=-68.932 tagged_above=-999 required=5
	tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994,
	GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955,
	HOST_EQ_BR=1.295, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5,
	RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
	RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666,
	SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 l0Teo6mCp34I; Tue, 10 Jun 2008 10:08:32 -0700 (PDT)
Received: from 201-15-125-209.cbabm300.ipd.brasiltelecom.net.br (201-15-125-209.cbabm300.ipd.brasiltelecom.net.br [201.15.125.209])
	by core3.amsl.com (Postfix) with SMTP id 1DA473A6811;
	Tue, 10 Jun 2008 10:07:23 -0700 (PDT)
X-Originating-IP: 181.11.29.150 by smtp.201.15.125.209;  Tue, 10 Jun 2008 13:07:43 -0500
Message-ID: <qealfJDDBOQtsv-area@ietf.org>
From: "Cassandra Quick" <tsv-area@ietf.org>
Reply-To: "Cassandra Quick" <tsv-area@ietf.org>
To: tsv-area@ietf.org
Subject: Rolex replica is a ultimate gift
Date: Tue, 10 Jun 2008 13:07:43 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today!
http://xepuroleseg48.blogspot.com/





From owner-v6ops@ops.ietf.org  Thu Jun 12 02:09:16 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DE44F3A693D
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 12 Jun 2008 02:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.591
X-Spam-Level: 
X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5
	tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001,
	USER_IN_WHITELIST=-100]
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 W3hQiG8tJvZ5
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 12 Jun 2008 02:09:16 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id CB85B28B56A
	for <v6ops-archive@lists.ietf.org>; Thu, 12 Jun 2008 02:09:15 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K6ifl-000881-7M
	for v6ops-data@psg.com; Thu, 12 Jun 2008 09:00:45 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <root@core3.amsl.com>)
	id 1K6ifW-000865-W1
	for v6ops@ops.ietf.org; Thu, 12 Jun 2008 09:00:42 +0000
Received: by core3.amsl.com (Postfix, from userid 0)
	id BB0823A693D; Thu, 12 Jun 2008 02:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
Subject: I-D Action:draft-ietf-v6ops-addr-select-ps-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080612090001.BB0823A693D@core3.amsl.com>
Date: Thu, 12 Jun 2008 02:00:01 -0700 (PDT)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.


	Title           : Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules
	Author(s)       : A. Matsumoto, et al.
	Filename        : draft-ietf-v6ops-addr-select-ps-07.txt
	Pages           : 17
	Date            : 2008-06-12

A single physical link can have multiple prefixes assigned to it.  In
that environment, end hosts might have multiple IP addresses and be
required to use them selectively.  RFC 3484 defines default source
and destination address selection rules and is implemented in a
variety of OS's.  But, it has been too difficult to use operationally
for several reasons.  In some environment where multiple prefixes are
assigned on a single physical link, the host using the default
address selection rules will experience some trouble in
communication.  This document describes the possible problems that
end hosts could encounter in an environment with multiple prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-addr-select-ps-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-06-12015728.I-D@ietf.org>

--NextPart--



From owner-v6ops@ops.ietf.org  Thu Jun 12 02:32:52 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B1BF23A69E4
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 12 Jun 2008 02:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5
	tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001,
	USER_IN_WHITELIST=-100]
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 1ogL5xdnhZol
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 12 Jun 2008 02:32:51 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id BF4E33A69AC
	for <v6ops-archive@lists.ietf.org>; Thu, 12 Jun 2008 02:32:51 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K6j8y-000Bmt-Ux
	for v6ops-data@psg.com; Thu, 12 Jun 2008 09:30:56 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <root@core3.amsl.com>)
	id 1K6j8Z-000Biz-5B
	for v6ops@ops.ietf.org; Thu, 12 Jun 2008 09:30:42 +0000
Received: by core3.amsl.com (Postfix, from userid 0)
	id C114C3A697D; Thu, 12 Jun 2008 02:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
Subject: I-D Action:draft-ietf-v6ops-addr-select-ps-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080612093001.C114C3A697D@core3.amsl.com>
Date: Thu, 12 Jun 2008 02:30:01 -0700 (PDT)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.


	Title           : Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules
	Author(s)       : A. Matsumoto, et al.
	Filename        : draft-ietf-v6ops-addr-select-ps-08.txt
	Pages           : 17
	Date            : 2008-06-12

A single physical link can have multiple prefixes assigned to it.  In
that environment, end hosts might have multiple IP addresses and be
required to use them selectively.  RFC 3484 defines default source
and destination address selection rules and is implemented in a
variety of OS's.  But, it has been too difficult to use operationally
for several reasons.  In some environment where multiple prefixes are
assigned on a single physical link, the host using the default
address selection rules will experience some trouble in
communication.  This document describes the possible problems that
end hosts could encounter in an environment with multiple prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-addr-select-ps-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-06-12021703.I-D@ietf.org>

--NextPart--



From c.neuhaus@witzleben-apotheke.de  Thu Jun 12 14:51:35 2008
Return-Path: <c.neuhaus@witzleben-apotheke.de>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BFDC43A6930;
	Thu, 12 Jun 2008 14:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -65.85
X-Spam-Level: 
X-Spam-Status: No, score=-65.85 tagged_above=-999 required=5
	tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357,
	FH_HOST_EQ_D_D_D_D=0.765, FS_REPLICA=0.994, GB_ROLEX=5,
	HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96,
	RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666,
	SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666,
	SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100]
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 MI3jL3YqH12q; Thu, 12 Jun 2008 14:51:35 -0700 (PDT)
Received: from host109.200-43-104.telecom.net.ar (host109.200-43-104.telecom.net.ar [200.43.104.109])
	by core3.amsl.com (Postfix) with SMTP id 0055D3A6843;
	Thu, 12 Jun 2008 14:51:25 -0700 (PDT)
X-Originating-IP: 243.58.49.106 by smtp.200.43.104.109;  Thu, 12 Jun 2008 17:51:54 -0500
Message-ID: <xuxzdoRGMMJtechspec@megatron.ietf.org>
From: "Carmela Butler" <techspec@megatron.ietf.org>
Reply-To: "Carmela Butler" <techspec@megatron.ietf.org>
To: techspec@megatron.ietf.org
Subject: Replica or Original?
Date: Thu, 12 Jun 2008 17:51:54 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers.
http://pokybunubyl43.blogspot.com/

Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal!
http://pokybunubyl43.blogspot.com/




From owner-v6ops@ops.ietf.org  Thu Jun 12 16:45:13 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 55B553A694F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 12 Jun 2008 16:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.4
X-Spam-Level: 
X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001,
	USER_IN_WHITELIST=-100]
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 YWHh00KpCP2l
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 12 Jun 2008 16:45:03 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id AEF6A3A681C
	for <v6ops-archive@lists.ietf.org>; Thu, 12 Jun 2008 16:45:02 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K6wNs-0005ru-Ga
	for v6ops-data@psg.com; Thu, 12 Jun 2008 23:39:12 +0000
Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <Jinmei_Tatuya@isc.org>)
	id 1K6wNo-0005rG-RA
	for v6ops@ops.ietf.org; Thu, 12 Jun 2008 23:39:10 +0000
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f])
	by mon.jinmei.org (Postfix) with ESMTP id 5DA6733C2E;
	Thu, 12 Jun 2008 16:39:08 -0700 (PDT)
Date: Thu, 12 Jun 2008 16:39:08 -0700
Message-ID: <m23aniustf.wl%Jinmei_Tatuya@isc.org>
From:	 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org>
To:	 "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Cc:	 <v6ops@ops.ietf.org>
Subject: Re: draft-ietf-v6ops-addcon 
In-Reply-To: <70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
References: <70672088D7D2CE409FB05DDD7B73D38101A43F9D@xmb-ams-33c.emea.cisco.com>
	 <70672088D7D2CE409FB05DDD7B73D38101A8827E@xmb-ams-33c.emea.cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

At Mon, 9 Jun 2008 04:49:34 +0200,
"Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> wrote:

> The question here is if different then /64 prefix considerations should
> be given?
> 
> At the moment any prefix NOT starting with '000' must have a 64bit
> network ID.
> The addcon draft documents items that 'if' one has to divert from this 
> recommendation (against any IETF doc) to at least be aware of other 
> restrictions regarding anycast, etc....
> 
> Now at IESG review that is contested, and the editors are trying to 
> understand if sections 3.1 (larger then /64) and 3.3 (smaller then /64)
> should 
> be removed or not?
> 
> I think it is good content as reality seems to indicate that people DO
> use 
> different then /64 prefix addresses.
> 
> Any thoughts? Flames? Screams?

We should keep both of these section.  This is indeed a very confusing
point, and we had a hard time providing reasonable explanation of this
prefix/IFID length issue when we revised the stateless addrconf
document (now published as RFC4862).  The following excerpt from
RFC4862 may help in this context, too.

      Note that a future revision of the address architecture [RFC4291]
      and a future link-type-specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.
(from Section 5.5.3)

I know it's still not crystal clear, but it was a best effort
compromise to make the description as consistent with other documents
as a possible, while still respecting existing
implementation/operational experiences and providing greater
flexibility.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



From owner-v6ops@ops.ietf.org  Thu Jun 12 16:55:47 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 84FF53A6A57
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 12 Jun 2008 16:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.4
X-Spam-Level: 
X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001,
	USER_IN_WHITELIST=-100]
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 TZphWxqfh+hw
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 12 Jun 2008 16:55:45 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 534863A67F1
	for <v6ops-archive@lists.ietf.org>; Thu, 12 Jun 2008 16:55:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K6wcG-0007mr-Pq
	for v6ops-data@psg.com; Thu, 12 Jun 2008 23:54:04 +0000
Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <Jinmei_Tatuya@isc.org>)
	id 1K6wcC-0007mM-I5
	for v6ops@ops.ietf.org; Thu, 12 Jun 2008 23:54:02 +0000
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f])
	by mon.jinmei.org (Postfix) with ESMTP id 39BB433C2E;
	Thu, 12 Jun 2008 16:54:00 -0700 (PDT)
Date: Thu, 12 Jun 2008 16:54:00 -0700
Message-ID: <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
From:	 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org>
To:	 Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Cc:	 v6ops@ops.ietf.org
Subject: Re: Router Solicitations
In-Reply-To: <484E4875.1040508@cs.uni-goettingen.de>
References: <484E4875.1040508@cs.uni-goettingen.de>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

At Tue, 10 Jun 2008 11:25:09 +0200,
Niklas Neumann <niklas.neumann@cs.uni-goettingen.de> wrote:

> I have a question regarding RFC 4861, Section 6.3.7. "Sending Router 
> Solicitations". The RFC states that when a host is sending a Router 
> Solicitation, "the IP source address is set to either one of the 
> interface's unicast addresses or the unspecified address."
> 
> So my question is
> 1) when is a host supposed to set a unicast address and
> 2) what qualifies as "one of the interface's unicast addresses?"

My understanding is:

1) whenever it has a valid unicast address (i.e., almost anytime)
2) any valid unicast addresses that are proved to be unique assigned
   to that interface

> For example: Is an implementation supposed to remember the last address 
> an interface had and to include this address in a Router Solicitation 
> after the host attaches to a new link?

No.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



From owner-v6ops@ops.ietf.org  Mon Jun 16 03:04:46 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 119E13A685C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 16 Jun 2008 03:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.05
X-Spam-Level: *
X-Spam-Status: No, score=1.05 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35,
	HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 tCY9Q8VcVVys
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 16 Jun 2008 03:04:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id B49443A6767
	for <v6ops-archive@lists.ietf.org>; Mon, 16 Jun 2008 03:04:44 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8BR6-000E7U-Iq
	for v6ops-data@psg.com; Mon, 16 Jun 2008 09:55:40 +0000
Received: from [217.72.192.227] (helo=fmmailgate02.web.de)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K8BQq-000E6C-03
	for v6ops@ops.ietf.org; Mon, 16 Jun 2008 09:55:33 +0000
Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216])
	by fmmailgate02.web.de (Postfix) with ESMTP id 88068E1CC8C2;
	Mon, 16 Jun 2008 11:55:22 +0200 (CEST)
Received: from [91.66.51.87] (helo=[192.168.221.137])
	by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256)
	(WEB.DE 4.109 #226)
	id 1K8BQo-0000TM-00; Mon, 16 Jun 2008 11:55:22 +0200
Message-ID: <48563881.2080103@cs.uni-goettingen.de>
Date: Mon, 16 Jun 2008 11:55:13 +0200
From: Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Organization: University of Goettingen
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?=
 <Jinmei_Tatuya@isc.org>
CC: v6ops@ops.ietf.org
Subject: Re: Router Solicitations
References: <484E4875.1040508@cs.uni-goettingen.de> <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
In-Reply-To: <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Sender: n.neumann@web.de
X-Provags-ID: V01U2FsdGVkX18vbrqW2XRfRIshdn6AyoO1fST+K5JlmB/FHJU1
	bt6leGAtqpIsgXG7HQfaa6xr8MHJnEUP81vlHiZCx31CqaJKX+
	cAhubHonQ=
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Thank you for your response. Just to make it perfectly clear to me:
How long is a unicast address valid?
- Until the host gets disconnected from the link?
- Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
- Some other trigger (e.g. L2 trigger)?

For example: If a host gets disconnected (e.g. wire gets pulled out) 
from a link and shortly after it gets reconnected. Does it send the 
Router Solicitation with its previous address or the unspecified address?

Thank you so much for answering.
Best regards
   Niklas


JINMEI Tatuya / 神明�哉 wrote:
> At Tue, 10 Jun 2008 11:25:09 +0200,
> Niklas Neumann <niklas.neumann@cs.uni-goettingen.de> wrote:
> 
>> I have a question regarding RFC 4861, Section 6.3.7. "Sending Router 
>> Solicitations". The RFC states that when a host is sending a Router 
>> Solicitation, "the IP source address is set to either one of the 
>> interface's unicast addresses or the unspecified address."
>>
>> So my question is
>> 1) when is a host supposed to set a unicast address and
>> 2) what qualifies as "one of the interface's unicast addresses?"
> 
> My understanding is:
> 
> 1) whenever it has a valid unicast address (i.e., almost anytime)
> 2) any valid unicast addresses that are proved to be unique assigned
>    to that interface
> 
>> For example: Is an implementation supposed to remember the last address 
>> an interface had and to include this address in a Router Solicitation 
>> after the host attaches to a new link?
> 
> No.
> 
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.


-- 
Niklas Neumann - University of Goettingen, Institute of Informatics
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-14419



From owner-v6ops@ops.ietf.org  Mon Jun 16 13:52:54 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EEE4728C154
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 16 Jun 2008 13:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.4
X-Spam-Level: 
X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001,
	USER_IN_WHITELIST=-100]
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 dkqU8juLgMnf
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 16 Jun 2008 13:52:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 1056028C14A
	for <v6ops-archive@lists.ietf.org>; Mon, 16 Jun 2008 13:52:54 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Lbo-000BuG-CZ
	for v6ops-data@psg.com; Mon, 16 Jun 2008 20:47:24 +0000
Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <Jinmei_Tatuya@isc.org>)
	id 1K8Lbk-000Btw-Qe
	for v6ops@ops.ietf.org; Mon, 16 Jun 2008 20:47:22 +0000
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f])
	by mon.jinmei.org (Postfix) with ESMTP id 81AFA33C2E;
	Mon, 16 Jun 2008 13:47:20 -0700 (PDT)
Date: Mon, 16 Jun 2008 13:47:20 -0700
Message-ID: <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
From:	 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org>
To:	 Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Cc:	 v6ops@ops.ietf.org
Subject: Re: Router Solicitations
In-Reply-To: <48563881.2080103@cs.uni-goettingen.de>
References: <484E4875.1040508@cs.uni-goettingen.de>
	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
	 <48563881.2080103@cs.uni-goettingen.de>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

At Mon, 16 Jun 2008 11:55:13 +0200,
Niklas Neumann <niklas.neumann@cs.uni-goettingen.de> wrote:

> Thank you for your response. Just to make it perfectly clear to me:
> How long is a unicast address valid?

Until its valid lifetime expires.

> - Until the host gets disconnected from the link?
> - Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
> - Some other trigger (e.g. L2 trigger)?

> For example: If a host gets disconnected (e.g. wire gets pulled out) 
> from a link and shortly after it gets reconnected. Does it send the 
> Router Solicitation with its previous address or the unspecified address?

Pure protocol-wise, the host would be supposed to perform duplicate
address detection again.  Once the uniqueness of the address is
(re)confirmed (normally in about 1 second), it can use that address as
the source of RS.  If it cannot wait for that period, it can send the
RS with an unspecified source address.

In practice, the behavior in such a case may vary among different
implementations, though.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



From owner-v6ops@ops.ietf.org  Mon Jun 16 16:13:32 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 034953A67FE
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 16 Jun 2008 16:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.443
X-Spam-Level: 
X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5
	tests=[AWL=-0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 zi4S3sLtkIc5
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 16 Jun 2008 16:13:26 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 86E4D3A6833
	for <v6ops-archive@lists.ietf.org>; Mon, 16 Jun 2008 16:13:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8NpC-0001Re-FX
	for v6ops-data@psg.com; Mon, 16 Jun 2008 23:09:22 +0000
Received: from [209.85.198.228] (helo=rv-out-0506.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K8Np7-0001QX-9h
	for v6ops@ops.ietf.org; Mon, 16 Jun 2008 23:09:19 +0000
Received: by rv-out-0506.google.com with SMTP id b25so6736609rvf.41
        for <v6ops@ops.ietf.org>; Mon, 16 Jun 2008 16:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:subject:content-type
         :content-transfer-encoding;
        bh=X9t9xAl6weFOkZZTEUD+Erf4b4U8KQOyvoA2hmme29I=;
        b=rRkStOGVzjMbvUGGWrv+uthwBTolQzldMQhpH8/oTgpnQWtWF+08TYiQ2lqHjAV0Mv
         7/SncF2tBMjeUnqQwszY4CeOgxT8HAIioIXTUfGs4B+QqtIbJNc2VhVGuNj5tQZ3qkHZ
         p/b2SjtaxoAXU2i+4MAm80s778jCJXChZzjB0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to
         :subject:content-type:content-transfer-encoding;
        b=QZc0nDRIC12dv0omL1nfrY+2D94wITfLdir6irCIBja+WlRtuknPtxh64wj20YaZJ6
         sLRtbyquCFE7kXSqGbyjF51ENJ47Wnu7uokoXrqLorm1oYUq+3UAJC5eS2IDORR2uU4u
         Q7uHoTJZoVrTHVdj0mRBeHWEuO/d22JctZIXk=
Received: by 10.142.188.4 with SMTP id l4mr2605165wff.151.1213657754824;
        Mon, 16 Jun 2008 16:09:14 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id 24sm86765wff.17.2008.06.16.16.09.13
        (version=SSLv3 cipher=RC4-MD5);
        Mon, 16 Jun 2008 16:09:14 -0700 (PDT)
Message-ID: <4856F297.50608@gmail.com>
Date: Tue, 17 Jun 2008 11:09:11 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Tunnel-to-NAT scenario
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi,

draft-bagnulo-behave-nat64-00.txt is being discussed
over on the BEHAVE list, and covers the case of an IPv6-only
initiator reaching an IPv4-only server.

I believe that we also need to come up with a solution for an
IPv4 initiator reaching a server with IPv6-only connectivity.
My question is whether we can be satisfied with a solution
that requires that server to be dual stack, so that it can
tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
(Crude diagram below.)
That seems a lot simpler than developing complete MNAT-PT
or SHANTI solutions, which in can case can never really
offer more transparency that conventional NAT.

If so, we could incorporate a tunnel-to-NAT scenario in
draft-ietf-v6ops-nat64-pb-statement-req.

    Brian

+------+-----+-------+          +------+-----+          +-----+------+
|Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
|      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
+------+-----+-------+          +------+-----+          +-----+------+




From owner-v6ops@ops.ietf.org  Mon Jun 16 17:26:38 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 642B53A6803
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 16 Jun 2008 17:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.34
X-Spam-Level: **
X-Spam-Status: No, score=2.34 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553,
	RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1]
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 KKgp3iL2ya9F
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 16 Jun 2008 17:26:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 6F51A3A67B1
	for <v6ops-archive@lists.ietf.org>; Mon, 16 Jun 2008 17:26:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8OxE-0009tc-Ju
	for v6ops-data@psg.com; Tue, 17 Jun 2008 00:21:44 +0000
Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <alain_durand@cable.comcast.com>)
	id 1K8OxA-0009t7-R8
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 00:21:42 +0000
Received: from ([10.195.246.152])
	by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.5597276;
	Mon, 16 Jun 2008 20:21:27 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 16 Jun 2008 20:21:27 -0400
Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.77]) with Microsoft Exchange Server HTTP-DAV ;
 Tue, 17 Jun 2008 00:21:27 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Mon, 16 Jun 2008 20:21:23 -0400
Subject: Re: Tunnel-to-NAT scenario
From: Alain Durand <alain_durand@cable.comcast.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,
	IPv6 Operations <v6ops@ops.ietf.org>
Message-ID: <C47C7BC3.126B6%alain_durand@cable.comcast.com>
Thread-Topic: Tunnel-to-NAT scenario
Thread-Index: AcjQCZNtMggmZNAqSYG2jOF2v9FkvwABn8qQ
In-Reply-To: <4856F297.50608@gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 17 Jun 2008 00:21:27.0564 (UTC) FILETIME=[154F6CC0:01C8D010]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Brian,

It appears that the 'crude diagram below' is identical to the latest
iteration of 464.

  - Alain.


On 6/16/08 7:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

> Hi,
> 
> draft-bagnulo-behave-nat64-00.txt is being discussed
> over on the BEHAVE list, and covers the case of an IPv6-only
> initiator reaching an IPv4-only server.
> 
> I believe that we also need to come up with a solution for an
> IPv4 initiator reaching a server with IPv6-only connectivity.
> My question is whether we can be satisfied with a solution
> that requires that server to be dual stack, so that it can
> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
> (Crude diagram below.)
> That seems a lot simpler than developing complete MNAT-PT
> or SHANTI solutions, which in can case can never really
> offer more transparency that conventional NAT.
> 
> If so, we could incorporate a tunnel-to-NAT scenario in
> draft-ietf-v6ops-nat64-pb-statement-req.
> 
>     Brian
> 
> +------+-----+-------+          +------+-----+          +-----+------+
> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
> +------+-----+-------+          +------+-----+          +-----+------+
> 
> 





From owner-v6ops@ops.ietf.org  Mon Jun 16 18:08:19 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 202653A6803
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 16 Jun 2008 18:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level: 
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5
	tests=[AWL=-0.907, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 h357EbKhkQ5f
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 16 Jun 2008 18:08:18 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 30C9B3A67EE
	for <v6ops-archive@lists.ietf.org>; Mon, 16 Jun 2008 18:08:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Pen-000EhU-S4
	for v6ops-data@psg.com; Tue, 17 Jun 2008 01:06:45 +0000
Received: from [209.85.198.226] (helo=rv-out-0506.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K8Pek-000EgW-Dz
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 01:06:44 +0000
Received: by rv-out-0506.google.com with SMTP id b25so6782022rvf.41
        for <v6ops@ops.ietf.org>; Mon, 16 Jun 2008 18:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=VTbtzhEba0urd3+errA60PS/XBATFe/JAo97THjUhQw=;
        b=rf69aHXJETKf2yQM21oXpSa+A3gDf2ZCvZjDvWoKRcUPzZrzBLlEmV8N2oHOQjvbO1
         j+ZmAOVoTf1iSzdteO9OsofZyxuAOjpFiRd9MP0Nv3QNZJ3+7cWPr4L4J66nCHKVOR/f
         v9d+Bo1rEVI0PgnVReSVrUSVQAN93M5oRDvJ0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=XN6S0ky7D4nw6SlAVdMZRJ0E/emag7epA5Z5TJXK2BOSYDQWyILd9eGtNXhlTuVU6v
         WGqHlTuE5GsDSEaiQLNK2AOEdZVyDajekGsIpNVF4oaNhA+wv6me53KjUZT8Xf7r7VSB
         oUAEhhCLXWnaVCjeVylH0RrHipCpW2Cq2Z2Pw=
Received: by 10.141.122.20 with SMTP id z20mr4271198rvm.93.1213664802103;
        Mon, 16 Jun 2008 18:06:42 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id k41sm9922332rvb.3.2008.06.16.18.06.40
        (version=SSLv3 cipher=RC4-MD5);
        Mon, 16 Jun 2008 18:06:41 -0700 (PDT)
Message-ID: <48570E28.9090409@gmail.com>
Date: Tue, 17 Jun 2008 13:06:48 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Alain Durand <alain_durand@cable.comcast.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47C7BC3.126B6%alain_durand@cable.comcast.com>
In-Reply-To: <C47C7BC3.126B6%alain_durand@cable.comcast.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Alain,

That's encouraging.

I think we need a decision at the level of the
problem statement, however.

   Brian

On 2008-06-17 12:21, Alain Durand wrote:
> Brian,
> 
> It appears that the 'crude diagram below' is identical to the latest
> iteration of 464.
> 
>   - Alain.
> 
> 
> On 6/16/08 7:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> 
>> Hi,
>>
>> draft-bagnulo-behave-nat64-00.txt is being discussed
>> over on the BEHAVE list, and covers the case of an IPv6-only
>> initiator reaching an IPv4-only server.
>>
>> I believe that we also need to come up with a solution for an
>> IPv4 initiator reaching a server with IPv6-only connectivity.
>> My question is whether we can be satisfied with a solution
>> that requires that server to be dual stack, so that it can
>> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
>> (Crude diagram below.)
>> That seems a lot simpler than developing complete MNAT-PT
>> or SHANTI solutions, which in can case can never really
>> offer more transparency that conventional NAT.
>>
>> If so, we could incorporate a tunnel-to-NAT scenario in
>> draft-ietf-v6ops-nat64-pb-statement-req.
>>
>>     Brian
>>
>> +------+-----+-------+          +------+-----+          +-----+------+
>> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
>> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
>> +------+-----+-------+          +------+-----+          +-----+------+
>>
>>
> 
> 
> 



From owner-v6ops@ops.ietf.org  Mon Jun 16 18:33:15 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 574A73A68A8
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 16 Jun 2008 18:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.34
X-Spam-Level: **
X-Spam-Status: No, score=2.34 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553,
	RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1]
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 TLRFOhAknx1t
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 16 Jun 2008 18:33:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 5CB4C3A67B7
	for <v6ops-archive@lists.ietf.org>; Mon, 16 Jun 2008 18:33:14 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Q1D-000HUd-Pi
	for v6ops-data@psg.com; Tue, 17 Jun 2008 01:29:55 +0000
Received: from [208.17.35.58] (helo=paoakoavas09.cable.comcast.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <alain_durand@cable.comcast.com>)
	id 1K8Q19-000HTm-92
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 01:29:53 +0000
Received: from ([24.40.15.92])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-NTF18.56577940;
	Mon, 16 Jun 2008 21:29:34 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 16 Jun 2008 21:29:34 -0400
Received: from 211.210.76.2 ([211.210.76.2]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ;
 Tue, 17 Jun 2008 01:29:33 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Mon, 16 Jun 2008 21:29:31 -0400
Subject: Re: Tunnel-to-NAT scenario
From: Alain Durand <alain_durand@cable.comcast.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Message-ID: <C47C8BBB.126CA%alain_durand@cable.comcast.com>
Thread-Topic: Tunnel-to-NAT scenario
Thread-Index: AcjQFm4ued8npuJtSV+J8GpxX1rbBgAAykNp
In-Reply-To: <48570E28.9090409@gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 17 Jun 2008 01:29:34.0289 (UTC) FILETIME=[99302C10:01C8D019]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Brian,

Please note that this work (464pb statement & solution) is taken to
softwires.

  - Alain.


On 6/16/08 9:06 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:

> Alain,
> 
> That's encouraging.
> 
> I think we need a decision at the level of the
> problem statement, however.
> 
>    Brian
> 
> On 2008-06-17 12:21, Alain Durand wrote:
>> Brian,
>> 
>> It appears that the 'crude diagram below' is identical to the latest
>> iteration of 464.
>> 
>>   - Alain.
>> 
>> 
>> On 6/16/08 7:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> draft-bagnulo-behave-nat64-00.txt is being discussed
>>> over on the BEHAVE list, and covers the case of an IPv6-only
>>> initiator reaching an IPv4-only server.
>>> 
>>> I believe that we also need to come up with a solution for an
>>> IPv4 initiator reaching a server with IPv6-only connectivity.
>>> My question is whether we can be satisfied with a solution
>>> that requires that server to be dual stack, so that it can
>>> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
>>> (Crude diagram below.)
>>> That seems a lot simpler than developing complete MNAT-PT
>>> or SHANTI solutions, which in can case can never really
>>> offer more transparency that conventional NAT.
>>> 
>>> If so, we could incorporate a tunnel-to-NAT scenario in
>>> draft-ietf-v6ops-nat64-pb-statement-req.
>>> 
>>>     Brian
>>> 
>>> +------+-----+-------+          +------+-----+          +-----+------+
>>> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
>>> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
>>> +------+-----+-------+          +------+-----+          +-----+------+
>>> 
>>> 
>> 
>> 
>> 





From owner-v6ops@ops.ietf.org  Tue Jun 17 00:44:53 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1356A3A6969
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 00:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.49
X-Spam-Level: **
X-Spam-Status: No, score=2.49 tagged_above=-999 required=5 tests=[AWL=-0.150,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768,
	HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3,
	RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1]
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 lEOG6AkNYM2E
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 00:44:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 0A0993A67A8
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 00:44:51 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8VqB-0008Sq-ML
	for v6ops-data@psg.com; Tue, 17 Jun 2008 07:42:55 +0000
Received: from [24.40.8.145] (helo=pacdcimo01.cable.comcast.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <alain_durand@cable.comcast.com>)
	id 1K8Vq6-0008Rw-Ak
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 07:42:53 +0000
Received: from ([24.40.15.92])
	by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.5611365;
	Tue, 17 Jun 2008 03:42:24 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 17 Jun 2008 03:42:23 -0400
Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.77]) with Microsoft Exchange Server HTTP-DAV ;
 Tue, 17 Jun 2008 07:42:23 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Tue, 17 Jun 2008 03:42:21 -0400
Subject: Re: Tunnel-to-NAT scenario
From: Alain Durand <alain_durand@cable.comcast.com>
To:  =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?=
 <remi.despres@free.fr>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Message-ID: <C47CE31D.12701%alain_durand@cable.comcast.com>
Thread-Topic: Tunnel-to-NAT scenario
Thread-Index: AcjQTazJVE6GLU9MeEu830nZeyFWjg==
In-Reply-To: <485769EE.8030503@free.fr>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 17 Jun 2008 07:42:23.0712 (UTC) FILETIME=[AE673E00:01C8D04D]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 6/17/08 3:38 AM, "R=E9mi Despr=E9s" <remi.despres@free.fr> wrote:

> Alain Durand  - Le 6/17/08 3:29 AM :
>> Brian,
>>=20
>> Please note that this work (464pb statement & solution) is taken to
>> softwires.
> is this to imply that the following drafts should from now on be
> discussed in Softwires?
> - draft-ietf-v6ops-nat64-pb-statement-req-00.txt
> - draft-bagnulo-behave-nat64-00.txt
> Any pointer to clarify where we stand would be useful.

No. I'm only talking about Nat464.

  - Alain.





From owner-v6ops@ops.ietf.org  Tue Jun 17 00:44:54 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id AAA413A6969
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 00:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.398
X-Spam-Level: 
X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 Ux5PITps5woC
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 00:44:54 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C4FBE3A67A8
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 00:44:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Vls-0007vs-W2
	for v6ops-data@psg.com; Tue, 17 Jun 2008 07:38:28 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K8Vlp-0007vQ-FV
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 07:38:27 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 529323EA0D0;
	Tue, 17 Jun 2008 09:38:24 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id DA8FD3EA0FC;
	Tue, 17 Jun 2008 09:38:23 +0200 (CEST)
Message-ID: <485769EE.8030503@free.fr>
Date: Tue, 17 Jun 2008 09:38:22 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Alain Durand <alain_durand@cable.comcast.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47C8BBB.126CA%alain_durand@cable.comcast.com>
In-Reply-To: <C47C8BBB.126CA%alain_durand@cable.comcast.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Alain Durand  - Le 6/17/08 3:29 AM :
> Brian,
> 
> Please note that this work (464pb statement & solution) is taken to
> softwires.
is this to imply that the following drafts should from now on be 
discussed in Softwires?
- draft-ietf-v6ops-nat64-pb-statement-req-00.txt
- draft-bagnulo-behave-nat64-00.txt
Any pointer to clarify where we stand would be useful.

Regards.

Rémi



From owner-v6ops@ops.ietf.org  Tue Jun 17 01:47:32 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B523E3A6961
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 01:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 WuMMAgsriIOJ
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 01:47:31 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id A8F023A68EF
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 01:47:31 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8WpY-000GNb-JM
	for v6ops-data@psg.com; Tue, 17 Jun 2008 08:46:20 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <root@core3.amsl.com>)
	id 1K8Wp1-000GHt-DW
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 08:46:04 +0000
Received: by core3.amsl.com (Postfix, from userid 0)
	id 43C5B3A6A56; Tue, 17 Jun 2008 01:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
Subject: I-D Action:draft-ietf-v6ops-addr-select-ps-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080617084502.43C5B3A6A56@core3.amsl.com>
Date: Tue, 17 Jun 2008 01:45:02 -0700 (PDT)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.


	Title           : Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules
	Author(s)       : A. Matsumoto, et al.
	Filename        : draft-ietf-v6ops-addr-select-ps-09.txt
	Pages           : 17
	Date            : 2008-06-17

A single physical link can have multiple prefixes assigned to it.  In
that environment, end hosts might have multiple IP addresses and be
required to use them selectively.  RFC 3484 defines default source
and destination address selection rules and is implemented in a
variety of OS's.  But, it has been too difficult to use operationally
for several reasons.  In some environment where multiple prefixes are
assigned on a single physical link, the host using the default
address selection rules will experience some trouble in
communication.  This document describes the possible problems that
end hosts could encounter in an environment with multiple prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-addr-select-ps-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-06-17013441.I-D@ietf.org>

--NextPart--



From owner-v6ops@ops.ietf.org  Tue Jun 17 01:47:58 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 817C43A6A51
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 01:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.398
X-Spam-Level: 
X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 3tEGiz9b7kl4
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 01:47:57 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 6BAFC3A6969
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 01:47:57 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8WnF-000GAJ-Sx
	for v6ops-data@psg.com; Tue, 17 Jun 2008 08:43:57 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K8Wn3-000G8Q-Fa
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 08:43:47 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id BE7B13EA15A;
	Tue, 17 Jun 2008 10:43:44 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 66DB33EA157;
	Tue, 17 Jun 2008 10:43:44 +0200 (CEST)
Message-ID: <4857793F.6020808@free.fr>
Date: Tue, 17 Jun 2008 10:43:43 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Alain Durand <alain_durand@cable.comcast.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com>
In-Reply-To: <C47CE31D.12701%alain_durand@cable.comcast.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Alain Durand  - Le 6/17/08 9:42 AM :
> On 6/17/08 3:38 AM, "Rémi Després" <remi.despres@free.fr> wrote:

>> Alain Durand  - Le 6/17/08 3:29 AM :
>>> Please note that this work (464pb statement & solution) is taken to
>>> softwires.
>> is this to imply that the following drafts should from now on be
>> discussed in Softwires?
>> - draft-ietf-v6ops-nat64-pb-statement-req-00.txt
>> - draft-bagnulo-behave-nat64-00.txt

> No. I'm only talking about Nat464.

Thanks.
Still ambiguous IMU on the "pb statement" part of 464, but OK.


BTW is there a place where what is meant by NAT464 or "464 NAT" is 
defined in more details than in 
http://www.arin.net/meetings/minutes/ARIN_XXI/PDF/tuesday/464-ARIN_Durand.pdf 
?


Rémi



From owner-v6ops@ops.ietf.org  Tue Jun 17 02:24:52 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CF8583A693B
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 02:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.105
X-Spam-Level: 
X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5
	tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_13=0.6,
	MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 0RUjc9kywVBx
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 02:24:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 13B503A68EF
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 02:24:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8XPm-000LgO-Vs
	for v6ops-data@psg.com; Tue, 17 Jun 2008 09:23:46 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8XPj-000Lfu-8V
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 09:23:45 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id 534D719867A;
	Tue, 17 Jun 2008 12:23:42 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 1EAA0198671;
	Tue, 17 Jun 2008 12:23:42 +0300 (EEST)
Message-ID: <485782C3.8090309@piuha.net>
Date: Tue, 17 Jun 2008 12:24:19 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
CC: Alain Durand <alain_durand@cable.comcast.com>, 
 IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr>
In-Reply-To: <4857793F.6020808@free.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Softwires is taking the solution that involves tunneling private-space 
v4 over a v6-only cloud, and then doing a NAT towards the public v4 
Internet.

The rest should still be discussed in V6OPS. Are we done with the 
problem statement, by the way? I would recommend completing it and 
shipping it as an RFC as soon as possible.

The actual protocol work (like Marcelo's draft on nat64, for instance) 
will happen elsewhere. The IESG is currently looking at rechartering 
BEHAVE WG to do this work.

Jari




From owner-v6ops@ops.ietf.org  Tue Jun 17 02:48:59 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6A47C3A6A80
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 02:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level: 
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=-0.646,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292, RDNS_NONE=0.1]
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 tDehOEIL6CvM
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 02:48:58 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 486193A6A6E
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 02:48:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8XiD-000O1z-RP
	for v6ops-data@psg.com; Tue, 17 Jun 2008 09:42:49 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K8Xhh-000NyW-I8
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 09:42:33 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 0E77F3EA134
	for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 11:42:16 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id D165C3EA0F7
	for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 11:42:15 +0200 (CEST)
Message-ID: <485786F6.5080408@free.fr>
Date: Tue, 17 Jun 2008 11:42:14 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: 464 scanarios - identifying the variety
References: <C47C7BC3.126B6%alain_durand@cable.comcast.com>
In-Reply-To: <C47C7BC3.126B6%alain_durand@cable.comcast.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Alain Durand  - Le 6/17/08 2:21 AM :
  > It appears that the 'crude diagram below' is identical to the latest
> iteration of 464.

> On 6/16/08 7:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>> If so, we could incorporate a tunnel-to-NAT scenario in
>> draft-ietf-v6ops-nat64-pb-statement-req.

>> +------+-----+-------+          +------+-----+          +-----+------+
>> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
>> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
>> +------+-----+-------+          +------+-----+          +-----+------+

A variety variety of 464 configurations, with pros and cons, are being 
discussed.
IMO they deserve some clarification.
(464 is taken here as meaning "any scenario where a source v4 packet has 
to be delivered to a destination in v4, possibly modified, via a v6-only 
zone.)

Let:
- Cx     mean  Client using x packets (4 or 6)
- Sy     mean  Server using y packets (4 or 6)
- 4p     mean  private IPv4 (10... etc)
- 4/6    mean  v4 in v6 encap-decap
- NATxy  mean  NAT with x inside to y outside
- Bc     mean IPv4 plus Address and port Borrowing Protocol-Client
- Bs     mean IPv4 plus Address and port Borrowing Protocol-Server

Then we have (at least) the following scenarios:

1.
(C4 4)--4p--(NAT44 4/6)--6--(4/6+ S4)
     The "Tunnel to NAT scenario" above of Brian
     (where the server needs a modified dual stack).

2.
(C4 4)--4p--(NAT46 6)--6--(6 NAT64)--4--(4 S4)
     The "464NAT demo at IETF71" of Alain, ref 
http://www.arin.net/meetings/minutes/ARIN_XXI/PDF/tuesday/464-ARIN_Durand.pdf.

3.
(C4 4)--4p--(NAT44 4/6)--6--(4/6 NAT44)--4--(4 S4)
     The SNAT of Ralph Droms, ref 
http://tools.ietf.org/id/draft-droms-softwires-snat-00.txt.



4.
(C4 4)--4p--(NAT44 Bc 4/6)--6--(4/6 Bs 4)--4--(4 S4)
     My NAT44+APBP scenario, ref sec. 2 of 
http://tools.ietf.org/id/draft-despres-v6ops-apbp-00.txt.


5.
(C4 Bc 4/6)--6--(4/6 Bs)--4--(4 S4)
     My APBP-E2E scenario,  sec 5.2 of 
http://tools.ietf.org/id/draft-despres-v6ops-apbp-00.txt.



Using some kind of shorthand like this one would IMO help identifying 
which scenario does what.


Regards.

Rémi



From owner-v6ops@ops.ietf.org  Tue Jun 17 03:09:54 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 284803A6A56
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 03:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level: 
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=-0.150,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35,
	HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 zSn5Uzl230nG
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 03:09:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 2652B3A6A43
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 03:09:53 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Y4E-0000s2-Os
	for v6ops-data@psg.com; Tue, 17 Jun 2008 10:05:34 +0000
Received: from [134.76.10.26] (helo=mailer.gwdg.de)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K8Y4A-0000rF-Oc
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 10:05:32 +0000
Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5])
	by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69)
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K8Y41-00071U-Le; Tue, 17 Jun 2008 12:05:21 +0200
Message-ID: <48578C61.8080302@cs.uni-goettingen.de>
Date: Tue, 17 Jun 2008 12:05:21 +0200
From: Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Organization: University of Goettingen
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?=
 <Jinmei_Tatuya@isc.org>
CC: v6ops@ops.ietf.org
Subject: Re: Router Solicitations
References: <484E4875.1040508@cs.uni-goettingen.de>	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>	 <48563881.2080103@cs.uni-goettingen.de> <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
In-Reply-To: <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: (clean) by exiscan+sophie
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

JINMEI Tatuya / 神明�哉 wrote:
>> Thank you for your response. Just to make it perfectly clear to me:
>> How long is a unicast address valid?
> 
> Until its valid lifetime expires.
> 
>> - Until the host gets disconnected from the link?
>> - Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
>> - Some other trigger (e.g. L2 trigger)?

So link disconnection or other L2 triggers are not supposed to have any 
impact on the lifetime?


Thank you and have a nice week,
Niklas

-- 
Niklas Neumann - University of Goettingen, Institute of Informatics
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-14419



From owner-v6ops@ops.ietf.org  Tue Jun 17 04:15:22 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4158F28C12C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 04:15:22 -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=[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 JkX8cCyqvCJ6
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 04:15:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 5CAA228C12A
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 04:15:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Z8x-0009XN-Dr
	for v6ops-data@psg.com; Tue, 17 Jun 2008 11:14:31 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <iljitsch@muada.com>)
	id 1K8Z8t-0009WK-9Y
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 11:14:29 +0000
Received: from [163.117.140.211] ([163.117.140.211])
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m5HBDqRF026678
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Jun 2008 13:13:52 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Message-Id: <7446ED57-C2AF-40D2-A993-42E8F592F049@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <4856F297.50608@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Tunnel-to-NAT scenario
Date: Tue, 17 Jun 2008 13:14:17 +0200
References: <4856F297.50608@gmail.com>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 17 jun 2008, at 1:09, Brian E Carpenter wrote:

> I believe that we also need to come up with a solution for an
> IPv4 initiator reaching a server with IPv6-only connectivity.
> My question is whether we can be satisfied with a solution
> that requires that server to be dual stack, so that it can
> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
> (Crude diagram below.)

[...]

> +------+-----+-------+          +------+-----+          +-----+------+
> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
> +------+-----+-------+          +------+-----+          +-----+------+

How does the tunneling help? The actual packet mangling should be  
simple enough, the problem is that the client can't express the IPv6  
destination in an IPv4 packet without modifications to the IPv4 client  
(and those modifications would be unlikely to work through middleboxes).



From owner-v6ops@ops.ietf.org  Tue Jun 17 04:15:31 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3571E28C125
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 04:15:31 -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=[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 8nkDuY93YlOX
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 04:15:30 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 7372028C135
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 04:15:29 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8Z5E-0008ym-8s
	for v6ops-data@psg.com; Tue, 17 Jun 2008 11:10:40 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <iljitsch@muada.com>)
	id 1K8Z5A-0008y1-4u
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 11:10:38 +0000
Received: from [163.117.140.211] ([163.117.140.211])
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m5HB9wJg026612
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Jun 2008 13:09:58 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>,
        Alain Durand <alain_durand@cable.comcast.com>,
        IPv6 Operations <v6ops@ops.ietf.org>
Message-Id: <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <485782C3.8090309@piuha.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Tunnel-to-NAT scenario
Date: Tue, 17 Jun 2008 13:10:23 +0200
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 17 jun 2008, at 11:24, Jari Arkko wrote:

> Softwires is taking the solution that involves tunneling private- 
> space v4 over a v6-only cloud, and then doing a NAT towards the  
> public v4 Internet.

I have a problem with that.

In my opinion, it's an open question whether tunneling is a better  
approach than translation for this use case (IPv4 clients connecting  
to IPv4 servers through an IPv6 network). Doing the work in softwires  
de facto answers that question through process rather than consensus.



From owner-v6ops@ops.ietf.org  Tue Jun 17 04:49:07 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4CEB43A6AE1
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 04:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level: 
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5
	tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 jcy3gyXdKj90
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 04:49:06 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 503753A6A0D
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 04:49:05 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8ZeW-000DeD-4S
	for v6ops-data@psg.com; Tue, 17 Jun 2008 11:47:08 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8ZeN-000Dce-Q8
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 11:47:05 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id D8AF91986E3;
	Tue, 17 Jun 2008 14:46:58 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 9C66619866A;
	Tue, 17 Jun 2008 14:46:58 +0300 (EEST)
Message-ID: <4857A458.6070104@piuha.net>
Date: Tue, 17 Jun 2008 14:47:36 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@muada.com>
CC: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>, 
 Alain Durand <alain_durand@cable.comcast.com>,
 IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com>
In-Reply-To: <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Iljitsch,

> In my opinion, it's an open question whether tunneling is a better 
> approach than translation for this use case (IPv4 clients connecting 
> to IPv4 servers through an IPv6 network). Doing the work in softwires 
> de facto answers that question through process rather than consensus.
Softwires have been told that they shall employ tunneling to cross the 
v6-only cloud. The NAT that I mentioned comes only after this; its 
almost completely a separate component (except for the fact that you 
need to know which tunnel interface packets came on to deal with 
overlapping RFC1918 space at the customer sites).

I hope no one is no longer arguing that we should do a double NAT. I 
think that would be wrong because tunneling ensures that your IPv4 
traffic is as intact as possible. Yes, it may eventually get NATted, but 
I do not want to create technology that forces you to do it no matter 
what is at the other end. For instance, with a tunnel-based crossing of 
the v6-only cloud customers sites that have public IPv4 space will not 
see any NAT effects.

Jari




From owner-v6ops@ops.ietf.org  Tue Jun 17 05:38:08 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A87163A67D7
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 05:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.183
X-Spam-Level: 
X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=0.215,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 RHvP7XBR9zej
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 05:38:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id D45C73A6AE7
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 05:38:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8aPZ-000LGn-6B
	for v6ops-data@psg.com; Tue, 17 Jun 2008 12:35:45 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K8aPQ-000LG1-G8
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 12:35:38 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id CA9753EA125;
	Tue, 17 Jun 2008 14:35:35 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 757023EA0E3;
	Tue, 17 Jun 2008 14:35:35 +0200 (CEST)
Message-ID: <4857AF96.6080806@free.fr>
Date: Tue, 17 Jun 2008 14:35:34 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net>
In-Reply-To: <4857A458.6070104@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Jari Arkko  - Le 6/17/08 1:47 PM :
> ... tunneling ensures that your IPv4 traffic is as intact as 
> possible.

In this respect, The APBP-E2E scenario of draft-despres-v6ops-apbp-00
sec. 5.2 goes *one step further* than Tunnel-to-NAT.

When a (modified) dual stack client connects to a v4-only server:
- v4 packets are unchanged E2E.
- The (dual stack) client application sees its public v4 address, so 
that no NAT is needed.

It then seems that, if and when time comes to discuss the APBP protocol, 
after the problem statement, Softwires would be the right place.


Regards.

Rémi





From owner-v6ops@ops.ietf.org  Tue Jun 17 05:40:35 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 61DFC3A68F5
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 05:40:35 -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=[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 CmPA9-nlOQVv
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 05:40:31 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 50A853A6A80
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 05:40:31 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8aU2-000M5w-0w
	for v6ops-data@psg.com; Tue, 17 Jun 2008 12:40:22 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <iljitsch@muada.com>)
	id 1K8aTu-000M3S-7D
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 12:40:20 +0000
Received: from [163.117.140.211] ([163.117.140.211])
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m5HCdaE9028111
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Tue, 17 Jun 2008 14:39:37 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Cc: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>,
        Alain Durand <alain_durand@cable.comcast.com>,
        IPv6 Operations <v6ops@ops.ietf.org>
Message-Id: <7E80D68E-014E-49A8-ADE7-B9066768200E@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <4857A458.6070104@piuha.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Tunnel-to-NAT scenario
Date: Tue, 17 Jun 2008 14:40:06 +0200
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 17 jun 2008, at 13:47, Jari Arkko wrote:

> I hope no one is no longer arguing that we should do a double NAT. I  
> think that would be wrong because tunneling ensures that your IPv4  
> traffic is as intact as possible. Yes, it may eventually get NATted,  
> but I do not want to create technology that forces you to do it no  
> matter what is at the other end. For instance, with a tunnel-based  
> crossing of the v6-only cloud customers sites that have public IPv4  
> space will not see any NAT effects.

I agree that in the case of passing IPv4 through IPv6 without NAT  
tunneling is better. However, the case that we're discussing here is  
the one where there is also NAT involved. In that case, pretty much  
all the fields in the IPv4 header are mangled/ignored anyway, so there  
is no real value in carrying them across the IPv6 cloud intact.

Basically, by borrowing 32 bits of the IPv6 destination in the IPv6  
header, we can compress away the entire IPv4 header because none of  
the fields in there are needed later.

By going one step further and also adjusting the transport checksums  
it's possible to use the same NAT64 that also serves IPv6 hosts that  
want to talk to IPv4 destinations, which saves implementing two sets  
of translators or translators that support two different types of  
translation.



From owner-v6ops@ops.ietf.org  Tue Jun 17 06:01:19 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9EB253A6A50
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 06:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Level: 
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5
	tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3,
	USER_IN_WHITELIST=-100]
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 SLcN3V-KODEx
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 06:01:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C6B383A68F5
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 06:01:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8an6-000PTq-7g
	for v6ops-data@psg.com; Tue, 17 Jun 2008 13:00:04 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8amv-000PRM-29
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 12:59:56 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id 7A1A0198671;
	Tue, 17 Jun 2008 15:59:51 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 3F60219866A;
	Tue, 17 Jun 2008 15:59:51 +0300 (EEST)
Message-ID: <4857B56C.6020207@piuha.net>
Date: Tue, 17 Jun 2008 16:00:28 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net> <4857AF96.6080806@free.fr>
In-Reply-To: <4857AF96.6080806@free.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Remi,

> In this respect, The APBP-E2E scenario of draft-despres-v6ops-apbp-00
> sec. 5.2 goes *one step further* than Tunnel-to-NAT.
>
> When a (modified) dual stack client connects to a v4-only server:
> - v4 packets are unchanged E2E.
> - The (dual stack) client application sees its public v4 address, so 
> that no NAT is needed.
>
> It then seems that, if and when time comes to discuss the APBP 
> protocol, after the problem statement, Softwires would be the right 
> place.

Does APBP involve host changes?

The work put to SOFTWIRE is a very specific task: cross the v6-only 
cloud using tunneling, allow optional fairly standard NATting at the 
other side to handle overlapping RFC1918 space, no changes at all in the 
subscriber sites or hosts. That WG has a lot of expertise in getting 
tunneling like this to work.

However, generally speaking other protocol work will go elsewhere, as 
soon as we know what that work is. The reason why SOFTWIRE is having a 
head start is that they are attacking a separable, reasonably well 
understood part of the overall space that fits the profile of an 
existing WG. We are looking at rechartering BEHAVE for the rest of the work.

Jari




From owner-v6ops@ops.ietf.org  Tue Jun 17 06:23:47 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 421E73A6934
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 06:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 U2k14gTY4Hn2
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 06:23:46 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C67E83A67B3
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 06:23:45 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8b8W-0003bh-EK
	for v6ops-data@psg.com; Tue, 17 Jun 2008 13:22:12 +0000
Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <rdenis@simphalempin.com>)
	id 1K8b8B-0003Xc-H0
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 13:22:01 +0000
Received: by yop.chewa.net (Postfix, from userid 33)
	id 8B0BAE50; Tue, 17 Jun 2008 15:21:50 +0200 (CEST)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Tunnel-to-NAT scenario
MIME-Version: 1.0
Date: Tue, 17 Jun 2008 15:21:50 +0200
From: Remi Denis-Courmont <rdenis@simphalempin.com>
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Organization: Remlab.net
In-Reply-To: <4856F297.50608@gmail.com>
References: <4856F297.50608@gmail.com>
Message-ID: <aca6dd0a459513d3f9f98570d277007b@chewa.net>
X-Sender: rdenis@simphalempin.com
User-Agent: RoundCube Webmail/0.1-rc2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


On Tue, 17 Jun 2008 11:09:11 +1200, Brian E Carpenter

<brian.e.carpenter@gmail.com> wrote:

> I believe that we also need to come up with a solution for an

> IPv4 initiator reaching a server with IPv6-only connectivity.

> My question is whether we can be satisfied with a solution

> that requires that server to be dual stack, so that it can

> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.

> (Crude diagram below.)



Operating systems will continue to ship with IPv4 built-in for as long as

it is useful (i.e. very long). On top of that, IPv6 and IPv4 support tend

to be intertwined if only for the sake of dual-stack functions (mapped

addresses, address selection, automatic transition mechanism setup, etc).



So I guess we can assume IPv4 support for as long as it is potentially

useful. This may also be a self-realizing prophecy: if dual-stack is needed

on IPv6-only nodes, IPv6-only nodes will continue to have dual-stack.



> That seems a lot simpler than developing complete MNAT-PT

> or SHANTI solutions, which in can case can never really

> offer more transparency that conventional NAT.



Indeed.



-- 

Rémi Denis-Courmont

http://www.remlab.net




From owner-v6ops@ops.ietf.org  Tue Jun 17 06:53:37 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D16CE3A6A80
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 06:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.237
X-Spam-Level: 
X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.162,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 js7KYfuS6Usu
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 06:53:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id EF25D3A69FB
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 06:53:36 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8bZl-0007MC-JL
	for v6ops-data@psg.com; Tue, 17 Jun 2008 13:50:21 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K8bYs-0007CW-HV
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 13:49:28 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id D8E313EA102;
	Tue, 17 Jun 2008 15:49:25 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id A35393EA115;
	Tue, 17 Jun 2008 15:49:25 +0200 (CEST)
Message-ID: <4857C0E4.1010704@free.fr>
Date: Tue, 17 Jun 2008 15:49:24 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net> <4857AF96.6080806@free.fr> <4857B56C.6020207@piuha.net>
In-Reply-To: <4857B56C.6020207@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Jari Arkko  - Le 6/17/08 3:00 PM :
> Does APBP involve host changes?
- No host change is "required". If there is none, the scenario that fits 
is NAT44+APBP in the CPE.
- In the APBP-E2E scenario, a dual stack client connects to a v4-only 
server. (The "change" in the dual stack, i.e. the APBP client support, 
is the price to get E2E v4 connections from a site hat has no public v4 
address.)

> The work put to SOFTWIRE is a very specific task: cross the v6-only 
> cloud using tunneling, allow optional fairly standard NATting at the 
> other side to handle overlapping RFC1918 space, no changes at all in the 
> subscriber sites or hosts. 
- "No change at all in the subsriber sites" seems strange to me.
IMU something has at least to be said for tunnels to be established and 
released, and for v4 packets to be routed to the tunnels.
- But I understand that, provided the softwires machinery is already 
present in the CPE, this can be a small change.

> 
> However, generally speaking other protocol work will go elsewhere, as 
> soon as we know what that work is. The reason why SOFTWIRE is having a 
> head start is that they are attacking a separable, reasonably well 
> understood part of the overall space that fits the profile of an 
> existing WG. We are looking at rechartering BEHAVE for the rest of the 
> work.
- Any WG is fine. The only concern is that respective scopes of Softwire 
and Behave aren't, at the end, both so restrictive that a solution like 
APBP, that uses tunnels and doesn't use NATs in all cases, has no place 
to be discussed.

Regards.

Rémi




From owner-v6ops@ops.ietf.org  Tue Jun 17 07:17:52 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E7E1F28C11C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 07:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.397
X-Spam-Level: 
X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5
	tests=[AWL=-0.098, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3,
	USER_IN_WHITELIST=-100]
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 ZuhGNAetPhqT
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 07:17:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 14A2C3A6B06
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 07:17:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8bxy-000AeC-97
	for v6ops-data@psg.com; Tue, 17 Jun 2008 14:15:22 +0000
Received: from [2001:14b8:400::23] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8bxX-000AbI-KJ
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 14:15:12 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id 7E3991986E3;
	Tue, 17 Jun 2008 17:14:54 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 34E6819867A;
	Tue, 17 Jun 2008 17:14:54 +0300 (EEST)
Message-ID: <4857C704.2040605@piuha.net>
Date: Tue, 17 Jun 2008 17:15:32 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net> <4857AF96.6080806@free.fr> <4857B56C.6020207@piuha.net> <4857C0E4.1010704@free.fr>
In-Reply-To: <4857C0E4.1010704@free.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Remi,

> - "No change at all in the subsriber sites" seems strange to me.

Obviously there has to be a change in the border between the subscriber 
site and the v6-only network. The tunneling box needs to do something. 
But no changes in the hosts in the subscriber side, for instance.

>>
>> However, generally speaking other protocol work will go elsewhere, as 
>> soon as we know what that work is. The reason why SOFTWIRE is having 
>> a head start is that they are attacking a separable, reasonably well 
>> understood part of the overall space that fits the profile of an 
>> existing WG. We are looking at rechartering BEHAVE for the rest of 
>> the work.
> - Any WG is fine. The only concern is that respective scopes of 
> Softwire and Behave aren't, at the end, both so restrictive that a 
> solution like APBP, that uses tunnels and doesn't use NATs in all 
> cases, has no place to be discussed.
Right. On initial look, your mechanism seems more of a general nature 
than the specific case sent to SOFTWIRE.

Jari




From owner-v6ops@ops.ietf.org  Tue Jun 17 09:41:45 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0D93D3A69DA
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 09:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.269
X-Spam-Level: 
X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=0.129,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 RHoCPr2Xpjin
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 09:41:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id E761F3A6991
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 09:41:43 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8eBQ-0003AU-Gt
	for v6ops-data@psg.com; Tue, 17 Jun 2008 16:37:24 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K8eBM-00039S-82
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 16:37:22 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 84CE23EA0CB;
	Tue, 17 Jun 2008 18:37:19 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 368833EA137;
	Tue, 17 Jun 2008 18:37:18 +0200 (CEST)
Message-ID: <4857E83C.1060708@free.fr>
Date: Tue, 17 Jun 2008 18:37:16 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net> <4857AF96.6080806@free.fr> <4857B56C.6020207@piuha.net> <4857C0E4.1010704@free.fr> <4857C704.2040605@piuha.net>
In-Reply-To: <4857C704.2040605@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Jari Arkko  - Le 6/17/08 4:15 PM :

> ... On initial look, your mechanism seems more of a general nature 
> than the specific case sent to SOFTWIRE.
IMHO it has more similarities with the work of SOFTWIRE than you have 
found:
- It has tunnels the endpoint of which can be in hosts or router CPEs.
- For the v4-v6 coexistence ad hoc functions are needed in both router 
CPEs and in ISP infrastructures.

The main difference with Tunnel-to-NAT, for the same 464 paths, is that 
NAT44 is in CPEs rather than in the ISP infrastructure.
- The disadvantage is more work left on specification (but IMO not so 
complex)
- The main advantage is a better scalability. (And the next advantage is 
E2E native IPv4 in client hosts that support APBP).

Anyway, it seems too early to decide where APBP would fit.
Discussing it in Dublin would IMO make sense.


Rémi








From owner-v6ops@ops.ietf.org  Tue Jun 17 10:24:07 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 81AB33A6B52
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 10:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level: 
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5
	tests=[AWL=-0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3,
	USER_IN_WHITELIST=-100]
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 A+Hqd6kzj+GI
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 10:23:49 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 3CB043A68E7
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 10:23:49 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8erN-0008eA-8h
	for v6ops-data@psg.com; Tue, 17 Jun 2008 17:20:45 +0000
Received: from [2001:41d0:1:a0d6::401:1983] (helo=yop.chewa.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <rdenis@simphalempin.com>)
	id 1K8eqh-0008YJ-Hs
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 17:20:05 +0000
Received: from basile.remlab.net (cs27058239.pp.htv.fi [89.27.58.239])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: remi)
	by yop.chewa.net (Postfix) with ESMTP id 3A328C2D;
	Tue, 17 Jun 2008 19:19:59 +0200 (CEST)
From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= <rdenis@simphalempin.com>
Organization: Remlab.net
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: Tunnel-to-NAT scenario
Date: Tue, 17 Jun 2008 20:19:57 +0300
User-Agent: KMail/1.9.9
Cc: IPv6 Operations <v6ops@ops.ietf.org>
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net>
In-Reply-To: <4857A458.6070104@piuha.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200806172019.57915.rdenis@simphalempin.com>
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Le mardi 17 juin 2008 14:47:36 Jari Arkko, vous avez =E9crit=A0:
> I hope no one is no longer arguing that we should do a double NAT. I
> think that would be wrong because tunneling ensures that your IPv4
> traffic is as intact as possible. Yes, it may eventually get NATted, but
> I do not want to create technology that forces you to do it no matter
> what is at the other end. For instance, with a tunnel-based crossing of
> the v6-only cloud customers sites that have public IPv4 space will not
> see any NAT effects.

Yeah. In practice, there may very well already be two NATs:
=2D the cheap off-the-shelf access point plugged in next to the 464 CPE [1],
=2D the hyper-NAT at the ISP end of the 464.

So you're talking about triple NAT :)
Indeed, that might not be such a great idea.


[1] However fully-feature the ISP-provided CPE may be, a significant=20
proportion of users will keep doing this.

=2D-=20
R=E9mi Denis-Courmont
http://www.remlab.net/



From owner-v6ops@ops.ietf.org  Tue Jun 17 10:24:20 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 77D123A6B42
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 10:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5
	tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 B79ynu6ZatiA
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 10:24:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 722B53A6B36
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 10:24:19 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8esS-0008pf-Kz
	for v6ops-data@psg.com; Tue, 17 Jun 2008 17:21:52 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8esJ-0008n4-SN
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 17:21:47 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id E820B1986ED;
	Tue, 17 Jun 2008 20:21:42 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 9A2F819866A;
	Tue, 17 Jun 2008 20:21:42 +0300 (EEST)
Message-ID: <4857F2CD.9030000@piuha.net>
Date: Tue, 17 Jun 2008 20:22:21 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>, 
 'IPv6 Operations' <v6ops@ops.ietf.org>
Subject: a comment on nat requirements draft
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

I was reading the requirements draft today, and I noticed this:

>    I5: MIPv6 support
>
>    The translation mechanism SHOULD not prevent MIPv6 Route Optimization
>    when the CN is a v4-only node
I'm not sure this requirement makes a lot of sense. An IPv4-only node 
clearly does not have any Mobile IPv6 code in it. Even if by some magic 
the RO packets were made to go through the NAT, the peer would drop them 
on the floor :-)

I actually believe R3 (allowing the use of native connectivity when 
dual-stack is available) already covers most of what we want to say 
about mobility in this context. That is, the NATted path should not take 
precedence over the native IPv6 path, because otherwise many things 
currently possible in IPv6 no longer work.

I don't know if you want to remove I5 altogether or consider saying 
something else. There is a need to allow two dual-stack hosts, one in 
v6-only network and the other in a v4-only network, to be able to use 
Mobile IPv6 route optimization with each other. But I don't know if our 
future NAT spec needs to include that, or if its simply an additional 
scenario for the Mobile IPv6 Dual Stack spec. That spec already allows a 
dual-stack mobile node to connect to its home agent over v4-only networks.

Jari




From owner-v6ops@ops.ietf.org  Tue Jun 17 12:23:42 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 288073A6B55
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 12:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.127
X-Spam-Level: 
X-Spam-Status: No, score=0.127 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 Bim5Vceck+T4
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 12:23:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 1C3253A699A
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 12:23:38 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8gid-000P4q-Rq
	for v6ops-data@psg.com; Tue, 17 Jun 2008 19:19:51 +0000
Received: from [64.233.178.248] (helo=hs-out-0708.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <ichiroumakino@gmail.com>)
	id 1K8giW-000P3W-0M
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 19:19:49 +0000
Received: by hs-out-0708.google.com with SMTP id z77so1177014hsz.9
        for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 12:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender
         :to:subject:cc:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references
         :x-google-sender-auth;
        bh=sXWQD63hnuXOFHjhrPfIFpqskxzcRRILZlFoIK16Bds=;
        b=GYnJvdfY64lO6VVgAWV1lE2jsiBvkZkqZdAorSePN/TQS7J8oAs5Xl/HO8TtmmYJEt
         oeS0DUaqsb8lJGA42Oc0JzdLOlm/XT/ARF03OLnCfMFj6nIs+sGT5e/wiE/NJbR+NjSe
         P1iZ2a27ACvwicqLVmDRgeow/YYN1VFeEccNQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=fKBoCU5anEBpjhwQ2gtK2jpB9Wr5WBm3uMSZkVkeExweyHNL53Mrvt2TU4IMeOW5ht
         ZWP9QSft7sKDlzClhj+IaT84Cd+yxfTVwGxAkEpdM/oUIcN7KpUxLI9CZ8UIdANl2g36
         r8crGZ5I/0y2eKAvcjkmZbdYuGLj4Gd1rldn4=
Received: by 10.151.142.16 with SMTP id u16mr13407835ybn.164.1213730383470;
        Tue, 17 Jun 2008 12:19:43 -0700 (PDT)
Received: by 10.151.26.7 with HTTP; Tue, 17 Jun 2008 12:19:43 -0700 (PDT)
Message-ID: <2bbba3c10806171219v21db85d4o3be1b294f9ef9e72@mail.gmail.com>
Date: Tue, 17 Jun 2008 21:19:43 +0200
From: "Ole Troan" <otroan@employees.org>
To: "Niklas Neumann" <niklas.neumann@cs.uni-goettingen.de>
Subject: Re: Router Solicitations
Cc: "=?BIG5?B?SklOTUVJIFRhdHV5YSAvIK+rqfq5Rqt2?=" <Jinmei_Tatuya@isc.org>, 
	v6ops@ops.ietf.org
In-Reply-To: <48578C61.8080302@cs.uni-goettingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <484E4875.1040508@cs.uni-goettingen.de>
	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
	 <48563881.2080103@cs.uni-goettingen.de>
	 <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
	 <48578C61.8080302@cs.uni-goettingen.de>
X-Google-Sender-Auth: 3d81f070ae38fb11
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

>>> Thank you for your response. Just to make it perfectly clear to me:
>>> How long is a unicast address valid?
>>
>> Until its valid lifetime expires.
>>
>>> - Until the host gets disconnected from the link?
>>> - Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
>>> - Some other trigger (e.g. L2 trigger)?
>
> So link disconnection or other L2 triggers are not supposed to have any
> impact on the lifetime?

not on address lifetime, but it is prudent to confirm address validity
on L2 reconnect.
the node might connect to a different link.

/ot



From owner-v6ops@ops.ietf.org  Tue Jun 17 12:24:25 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 26DCF3A6B5C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 12:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.1
X-Spam-Level: 
X-Spam-Status: No, score=-99.1 tagged_above=-999 required=5 tests=[AWL=-0.300,
	BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_13=0.6,
	NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 8+ehDdh8gxtU
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 12:24:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 3DEDB3A6B5D
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 12:24:21 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8gmi-000PXr-68
	for v6ops-data@psg.com; Tue, 17 Jun 2008 19:24:04 +0000
Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <Jinmei_Tatuya@isc.org>)
	id 1K8gmc-000PWz-Gj
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 19:24:01 +0000
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f])
	by mon.jinmei.org (Postfix) with ESMTP id 9CBB933C2E;
	Tue, 17 Jun 2008 12:23:57 -0700 (PDT)
Date: Tue, 17 Jun 2008 12:23:57 -0700
Message-ID: <m2skvbyieq.wl%Jinmei_Tatuya@isc.org>
From:	 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org>
To:	 Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Cc:	 v6ops@ops.ietf.org
Subject: Re: Router Solicitations
In-Reply-To: <48578C61.8080302@cs.uni-goettingen.de>
References: <484E4875.1040508@cs.uni-goettingen.de>
	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
	 <48563881.2080103@cs.uni-goettingen.de>
	 <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
	 <48578C61.8080302@cs.uni-goettingen.de>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

At Tue, 17 Jun 2008 12:05:21 +0200,
Niklas Neumann <niklas.neumann@cs.uni-goettingen.de> wrote:

> >> Thank you for your response. Just to make it perfectly clear to me:
> >> How long is a unicast address valid?
> > 
> > Until its valid lifetime expires.
> > 
> >> - Until the host gets disconnected from the link?
> >> - Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
> >> - Some other trigger (e.g. L2 trigger)?
> 
> So link disconnection or other L2 triggers are not supposed to have any 
> impact on the lifetime?

No.

I don't know why you're so much worrying about such corner cases.
Maybe you have some specific implementation and/or situation in your
mind where the interpretation of these points matter much.  As a
separate followup indicated, you may want to explain your intended
scenario.  Otherwise the discussion would be superficial (e.g. I can
only say 'No' because it's the answer and I don't know the background
intent of the question).

p.s. I've not noticed this thread has been sent to v6ops.  The 6man
list (ipv6@ietf.org) would be a better place for this topic.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



From owner-v6ops@ops.ietf.org  Tue Jun 17 13:07:19 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E10413A6994
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 13:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.926
X-Spam-Level: 
X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5
	tests=[AWL=-0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 HmvtG55sJ0nv
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 13:07:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id E7F593A6932
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 13:07:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8hRI-000529-C4
	for v6ops-data@psg.com; Tue, 17 Jun 2008 20:06:00 +0000
Received: from [163.117.176.133] (helo=smtp03.uc3m.es)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <marcelo@it.uc3m.es>)
	id 1K8hRD-00051I-L4
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 20:05:58 +0000
Received: from marcelo-bagnulos-macbook-pro.local 
	(134.pool85-53-139.dynamic.orange.es [85.53.139.134])by smtp03.uc3m.es 
	(Postfix) with ESMTP id 3B9973E98E6;Tue, 17 Jun 2008 22:05:53 +0200 (CEST)
Message-ID: <48581911.9010806@it.uc3m.es>
Date: Tue, 17 Jun 2008 22:05:37 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
CC: 'IPv6 Operations' <v6ops@ops.ietf.org>
Subject: Re: a comment on nat requirements draft
References: <4857F2CD.9030000@piuha.net>
In-Reply-To: <4857F2CD.9030000@piuha.net>
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-10.4435 TC:1F TRN:33 TV:5.5.1026(15978.001)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Jari Arkko escribió:
> I was reading the requirements draft today, and I noticed this:
>
>>    I5: MIPv6 support
>>
>>    The translation mechanism SHOULD not prevent MIPv6 Route Optimization
>>    when the CN is a v4-only node
> I'm not sure this requirement makes a lot of sense. An IPv4-only node 
> clearly does not have any Mobile IPv6 code in it. Even if by some 
> magic the RO packets were made to go through the NAT, the peer would 
> drop them on the floor :-)
what people had in mind was that the NAT box could perform the RO on 
behalf of the v4 CN, but some people already said that this wasn't that 
useful neither, what do you think?

regards, marcelo

>
> I actually believe R3 (allowing the use of native connectivity when 
> dual-stack is available) already covers most of what we want to say 
> about mobility in this context. That is, the NATted path should not 
> take precedence over the native IPv6 path, because otherwise many 
> things currently possible in IPv6 no longer work.
>
> I don't know if you want to remove I5 altogether or consider saying 
> something else. There is a need to allow two dual-stack hosts, one in 
> v6-only network and the other in a v4-only network, to be able to use 
> Mobile IPv6 route optimization with each other. But I don't know if 
> our future NAT spec needs to include that, or if its simply an 
> additional scenario for the Mobile IPv6 Dual Stack spec. That spec 
> already allows a dual-stack mobile node to connect to its home agent 
> over v4-only networks.
>
> Jari
>
>
>




From owner-v6ops@ops.ietf.org  Tue Jun 17 13:29:10 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 97ED23A6AB7
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 13:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level: 
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5
	tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 3k5Cz0kyd8sn
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 13:29:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 96B553A68B4
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 13:29:09 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8hjp-0007HD-5e
	for v6ops-data@psg.com; Tue, 17 Jun 2008 20:25:09 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8hjl-0007Gd-Ap
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 20:25:07 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id 2409719867A;
	Tue, 17 Jun 2008 23:25:04 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id CE7BA198671;
	Tue, 17 Jun 2008 23:25:03 +0300 (EEST)
Message-ID: <48581DC6.3080908@piuha.net>
Date: Tue, 17 Jun 2008 23:25:42 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
CC: 'IPv6 Operations' <v6ops@ops.ietf.org>
Subject: Re: a comment on nat requirements draft
References: <4857F2CD.9030000@piuha.net> <48581911.9010806@it.uc3m.es>
In-Reply-To: <48581911.9010806@it.uc3m.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Marcelo,

> what people had in mind was that the NAT box could perform the RO on 
> behalf of the v4 CN, but some people already said that this wasn't 
> that useful neither, what do you think?

Uh-oh.

That might be doable in the base RFC 3775 mobility, but not in any of 
the extensions (shared secret keying for RO, for instance).

I question the goal to attempt full feature parity. I would spend your 
cycles more wisely and try to make sure that if both v4 and v6 are 
available, you choose v6, making it possible to use any feature.

Or in my opinion this is right at least for mobility route optimization. 
It is indeed just an optimization. Even with direct IPv6 connectivity 
there is no way to guarantee that the optimization is supported by the 
implementation of the peer, accepted policy-wise by the peer, or passes 
through firewalls in between. That's why the optimization is designed to 
be fail-safe. If you can turn it on, great. If you cannot, things will 
still work.

Jari




From owner-v6ops@ops.ietf.org  Tue Jun 17 14:04:39 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 78AD33A68B4
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 14:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level: 
X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5
	tests=[AWL=-0.596, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 vAkikdGqyZHQ
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 14:04:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id A7AB23A695B
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 14:04:34 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8iKf-000Bb3-07
	for v6ops-data@psg.com; Tue, 17 Jun 2008 21:03:13 +0000
Received: from [163.117.176.132] (helo=smtp02.uc3m.es)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <marcelo@it.uc3m.es>)
	id 1K8iKX-000BZW-1l
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 21:03:07 +0000
Received: from marcelo-bagnulos-macbook-pro.local 
	(134.pool85-53-139.dynamic.orange.es [85.53.139.134])by smtp02.uc3m.es 
	(Postfix) with ESMTP id B4F493C8F08;Tue, 17 Jun 2008 23:02:41 +0200 (CEST)
Message-ID: <48582671.5060900@it.uc3m.es>
Date: Tue, 17 Jun 2008 23:02:41 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
CC: 'IPv6 Operations' <v6ops@ops.ietf.org>
Subject: Re: a comment on nat requirements draft
References: <4857F2CD.9030000@piuha.net> <48581911.9010806@it.uc3m.es> 
	<48581DC6.3080908@piuha.net>
In-Reply-To: <48581DC6.3080908@piuha.net>
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-12.2655 TC:1F TRN:30 TV:5.5.1026(15978.002)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

so, i understand that you are ok with dropping this one?


Jari Arkko escribió:
> Marcelo,
>
>> what people had in mind was that the NAT box could perform the RO on 
>> behalf of the v4 CN, but some people already said that this wasn't 
>> that useful neither, what do you think?
>
> Uh-oh.
>
> That might be doable in the base RFC 3775 mobility, but not in any of 
> the extensions (shared secret keying for RO, for instance).
>
> I question the goal to attempt full feature parity. I would spend your 
> cycles more wisely and try to make sure that if both v4 and v6 are 
> available, you choose v6, making it possible to use any feature.
>
> Or in my opinion this is right at least for mobility route 
> optimization. It is indeed just an optimization. Even with direct IPv6 
> connectivity there is no way to guarantee that the optimization is 
> supported by the implementation of the peer, accepted policy-wise by 
> the peer, or passes through firewalls in between. That's why the 
> optimization is designed to be fail-safe. If you can turn it on, 
> great. If you cannot, things will still work.
>
> Jari
>
>
>




From owner-v6ops@ops.ietf.org  Tue Jun 17 14:31:38 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4D67B3A6867
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 14:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level: 
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5
	tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 hQcggHriIXfp
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 14:31:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 676D93A680A
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 14:31:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8iix-000ENJ-DT
	for v6ops-data@psg.com; Tue, 17 Jun 2008 21:28:19 +0000
Received: from [2001:14b8:400::130] (helo=smtp.piuha.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <jari.arkko@piuha.net>)
	id 1K8iit-000EMd-IH
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 21:28:17 +0000
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id BA59619867A;
	Wed, 18 Jun 2008 00:28:13 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 61CFF198671;
	Wed, 18 Jun 2008 00:28:13 +0300 (EEST)
Message-ID: <48582C94.3000304@piuha.net>
Date: Wed, 18 Jun 2008 00:28:52 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
CC: 'IPv6 Operations' <v6ops@ops.ietf.org>
Subject: Re: a comment on nat requirements draft
References: <4857F2CD.9030000@piuha.net> <48581911.9010806@it.uc3m.es> 	<48581DC6.3080908@piuha.net> <48582671.5060900@it.uc3m.es>
In-Reply-To: <48582671.5060900@it.uc3m.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Yes.

Jari

marcelo bagnulo braun wrote:
> so, i understand that you are ok with dropping this one?
>
>
> Jari Arkko escribió:
>> Marcelo,
>>
>>> what people had in mind was that the NAT box could perform the RO on 
>>> behalf of the v4 CN, but some people already said that this wasn't 
>>> that useful neither, what do you think?
>>
>> Uh-oh.
>>
>> That might be doable in the base RFC 3775 mobility, but not in any of 
>> the extensions (shared secret keying for RO, for instance).
>>
>> I question the goal to attempt full feature parity. I would spend 
>> your cycles more wisely and try to make sure that if both v4 and v6 
>> are available, you choose v6, making it possible to use any feature.
>>
>> Or in my opinion this is right at least for mobility route 
>> optimization. It is indeed just an optimization. Even with direct 
>> IPv6 connectivity there is no way to guarantee that the optimization 
>> is supported by the implementation of the peer, accepted policy-wise 
>> by the peer, or passes through firewalls in between. That's why the 
>> optimization is designed to be fail-safe. If you can turn it on, 
>> great. If you cannot, things will still work.
>>
>> Jari
>>
>>
>>
>
>
>




From owner-v6ops@ops.ietf.org  Tue Jun 17 14:46:30 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 44C633A69AE
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 14:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.364
X-Spam-Level: 
X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5
	tests=[AWL=-0.869, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 QxYAh4i5f-9R
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 14:46:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id E94303A690C
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 14:46:28 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8izc-000GTj-FN
	for v6ops-data@psg.com; Tue, 17 Jun 2008 21:45:32 +0000
Received: from [64.233.166.180] (helo=py-out-1112.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K8izY-000GTB-T0
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 21:45:30 +0000
Received: by py-out-1112.google.com with SMTP id d32so2213359pye.19
        for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 14:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=fxwVi6WCGG+DevkpvT04t3vfznDWqUMe/5fGCLbL1f0=;
        b=WttXi7ux1Q/F9uAD/yTO6/66d/DBY681U1Omd+EWeEyASq9/Sncld0pjmHwX5u3js+
         uc6uSiDuQN6XNIxfDxFaswjxWtrBHg92Iq2fHgGDh7g/na7bkstpMPw+MSQ+peupO15P
         AWuhwDKFU4CGtT/c/6wZAtABKlqnBHELq1Vi8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=ZbW3PK6G9csAAbP9L/ruETsHtrFHR9HApOus5CgkuhbKdocrmrz4/ZCBRVQAiowdQ+
         KmR94B6o0sdVvmJMdClxYYi5ZDdwyH93kqX0XeIzm57ErwcY1aLt4m2iBdcfnvmja3P5
         VwvzlS4kl/JtySPbKHbALoj/qNkVrjelcf8/E=
Received: by 10.114.89.1 with SMTP id m1mr8767970wab.126.1213739127254;
        Tue, 17 Jun 2008 14:45:27 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id k9sm12259468wah.7.2008.06.17.14.45.26
        (version=SSLv3 cipher=RC4-MD5);
        Tue, 17 Jun 2008 14:45:27 -0700 (PDT)
Message-ID: <48583075.2020408@gmail.com>
Date: Wed, 18 Jun 2008 09:45:25 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@muada.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <4856F297.50608@gmail.com> <7446ED57-C2AF-40D2-A993-42E8F592F049@muada.com>
In-Reply-To: <7446ED57-C2AF-40D2-A993-42E8F592F049@muada.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Iljitsch,

On 2008-06-17 23:14, Iljitsch van Beijnum wrote:
> On 17 jun 2008, at 1:09, Brian E Carpenter wrote:
> 
>> I believe that we also need to come up with a solution for an
>> IPv4 initiator reaching a server with IPv6-only connectivity.
>> My question is whether we can be satisfied with a solution
>> that requires that server to be dual stack, so that it can
>> tunnel IPv4 in IPv6 to a conventional IPv4-to-IPv4 NAT.
>> (Crude diagram below.)
> 
> [...]
> 
>> +------+-----+-------+          +------+-----+          +-----+------+
>> |Server|IPv4 |Encaps |__________|Decaps|NAT44|__________|IPv4 |Client|
>> |      |stack|in IPv6| IPv6 net |      |     | IPv4 net |stack|      |
>> +------+-----+-------+          +------+-----+          +-----+------+
> 
> How does the tunneling help?

Er, it gets IPv4 packets across the IPv6-only network.

> The actual packet mangling should be simple
> enough, the problem is that the client can't express the IPv6
> destination in an IPv4 packet without modifications to the IPv4 client
> (and those modifications would be unlikely to work through middleboxes).

That's why you go to a traditional v4-to-v4 NAT at the boundary.
No new mangling code is needed. From the v4 point of view this
is bog standard NAPT with configured port mapping. I'll have to
look at Alain's draft to see if he's already written up the
whole thing, or if I need to write more.

    Brian



From owner-v6ops@ops.ietf.org  Tue Jun 17 15:03:38 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DB0503A690C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 15:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.248
X-Spam-Level: 
X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5
	tests=[AWL=-1.649, 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 Amrx0fGMA25n
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 15:03:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id F2A4B3A68BB
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 15:03:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8jG3-000Ia0-I9
	for v6ops-data@psg.com; Tue, 17 Jun 2008 22:02:31 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <iljitsch@muada.com>)
	id 1K8jFz-000IZC-7c
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 22:02:29 +0000
Received: from [192.168.2.13] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged))
	(authenticated bits=0)
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m5HM1p81037209
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Wed, 18 Jun 2008 00:01:52 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Cc: IPv6 Operations <v6ops@ops.ietf.org>
Message-Id: <C17751DB-0506-49B2-93FD-812E41A8EDA9@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <48583075.2020408@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Tunnel-to-NAT scenario
Date: Wed, 18 Jun 2008 00:02:17 +0200
References: <4856F297.50608@gmail.com> <7446ED57-C2AF-40D2-A993-42E8F592F049@muada.com> <48583075.2020408@gmail.com>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 17 jun 2008, at 23:45, Brian E Carpenter wrote:

>> The actual packet mangling should be simple
>> enough, the problem is that the client can't express the IPv6
>> destination in an IPv4 packet without modifications to the IPv4  
>> client
>> (and those modifications would be unlikely to work through  
>> middleboxes).

> That's why you go to a traditional v4-to-v4 NAT at the boundary.
> No new mangling code is needed. From the v4 point of view this
> is bog standard NAPT with configured port mapping.

So if you're an IPv4 client and I'm an IPv6 server with address  
2001:db8:31::1, what do you put in the destination address of the IPv4  
packets you send to me?




From owner-v6ops@ops.ietf.org  Tue Jun 17 15:08:02 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C28633A6946
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 15:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Level: 
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5
	tests=[AWL=-1.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
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 IL5IRG1hGah6
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 15:08:02 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id EAD963A690C
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 15:08:01 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8jLE-000JFb-1A
	for v6ops-data@psg.com; Tue, 17 Jun 2008 22:07:52 +0000
Received: from [64.233.166.181] (helo=py-out-1112.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K8jLA-000JEv-KF
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 22:07:50 +0000
Received: by py-out-1112.google.com with SMTP id d32so2221662pye.19
        for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 15:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=8G9pKOBDV09v8cv5OoHZnbdl4PsFFogyAoitzA2oB/M=;
        b=AixTKPejuSY21COhxadorbi4tLi+asJrV8q0Dbftq3ZA5hS5ekNLbuoWQjNy0skYC6
         VdgZKuyLkwENAt8pQk9DX0mOTGJi4/4FeK0pW28QUvVGNVBkkAsL+0Cub2vCjpBiVx02
         4D2egwx9AJOXFY6GyBIcjhcE0iwSQRJYpMG1k=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=P+Efs/Kwx7REAXAKIbAkjWHzbV/byEEomthI6KfrI9CPQwkbh/diOxWMOeYpilLXAL
         Rryj2Ll5ikvdeSUxAvcbSYXt5UQdHaCXT532kv3PHmPi9TuUbGBWG9OSS6H2vTbYnIA5
         7dd/K6i7SzZR+Ft693dl45xosaHKQDO01qdFk=
Received: by 10.115.16.1 with SMTP id t1mr8809302wai.49.1213740467641;
        Tue, 17 Jun 2008 15:07:47 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id l37sm9684897waf.23.2008.06.17.15.07.46
        (version=SSLv3 cipher=RC4-MD5);
        Tue, 17 Jun 2008 15:07:47 -0700 (PDT)
Message-ID: <485835B0.90009@gmail.com>
Date: Wed, 18 Jun 2008 10:07:44 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Alain Durand <alain_durand@cable.comcast.com>
CC: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= <remi.despres@free.fr>, 
 IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com>
In-Reply-To: <C47CE31D.12701%alain_durand@cable.comcast.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 2008-06-17 19:42, Alain Durand wrote:
> On 6/17/08 3:38 AM, "R=C3=A9mi Despr=C3=A9s" <remi.despres@free.fr> wro=
te:
>=20
>> Alain Durand  - Le 6/17/08 3:29 AM :
>>> Brian,
>>>
>>> Please note that this work (464pb statement & solution) is taken to
>>> softwires.
>> is this to imply that the following drafts should from now on be
>> discussed in Softwires?
>> - draft-ietf-v6ops-nat64-pb-statement-req-00.txt
>> - draft-bagnulo-behave-nat64-00.txt
>> Any pointer to clarify where we stand would be useful.
>=20
> No. I'm only talking about Nat464.

And I was referring to draft-ietf-v6ops-nat64-pb-statement.

If 464 solves this problem, fine, but we should keep the
overview in v6ops, I believe.

   Brian




From owner-v6ops@ops.ietf.org  Tue Jun 17 15:19:12 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6268A3A6B72
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 15:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.296
X-Spam-Level: 
X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5
	tests=[AWL=-0.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 C67W44jnyYMP
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 15:19:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 46C223A69B4
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 15:19:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8jVL-000Kag-El
	for v6ops-data@psg.com; Tue, 17 Jun 2008 22:18:19 +0000
Received: from [64.233.166.176] (helo=py-out-1112.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K8jVH-000Ka7-7h
	for v6ops@ops.ietf.org; Tue, 17 Jun 2008 22:18:16 +0000
Received: by py-out-1112.google.com with SMTP id d32so2225305pye.19
        for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 15:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=T2MmXPXuDVgzIYYOuQIQBsVil7/Bs6+yff6X810URPc=;
        b=BpH+nJGs5Fp5MrkT/hNbjAYQHfmsCmUOGcPReNMyvTJ9NAHIw/IHVLi9OzZLxhScfa
         C8IlKWeaVaKoJnA/3m/dhSmXgrMoiAPnN34EuyqZPCJWn2Z7emKHyrcw2LviMRDuzOPE
         c+GoSFdrcb4w6+Rn02Npo6Dxd0+Roz/NyxHw8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=UwrUFl77eVmEI1G+BWKk31hSW7DcMJB7Fq+i6N2RdcQk8ZlyaPs/j+5Ue5fT2TA63X
         cGpyEcE3TxmS7xVK6hXpA52nYqc3E8+suh2R/k7+wolqSwpk7qWHJal28c0eJFqp7Tnj
         Rgd+Vm0j34OPuSaWO3aA0MGm8dm+OY5qtnP/w=
Received: by 10.114.124.12 with SMTP id w12mr8749852wac.210.1213741091690;
        Tue, 17 Jun 2008 15:18:11 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id g25sm9756776wag.4.2008.06.17.15.18.10
        (version=SSLv3 cipher=RC4-MD5);
        Tue, 17 Jun 2008 15:18:11 -0700 (PDT)
Message-ID: <48583820.8080600@gmail.com>
Date: Wed, 18 Jun 2008 10:18:08 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@muada.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <4856F297.50608@gmail.com> <7446ED57-C2AF-40D2-A993-42E8F592F049@muada.com> <48583075.2020408@gmail.com> <C17751DB-0506-49B2-93FD-812E41A8EDA9@muada.com>
In-Reply-To: <C17751DB-0506-49B2-93FD-812E41A8EDA9@muada.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 2008-06-18 10:02, Iljitsch van Beijnum wrote:
> On 17 jun 2008, at 23:45, Brian E Carpenter wrote:
> 
>>> The actual packet mangling should be simple
>>> enough, the problem is that the client can't express the IPv6
>>> destination in an IPv4 packet without modifications to the IPv4 client
>>> (and those modifications would be unlikely to work through middleboxes).
> 
>> That's why you go to a traditional v4-to-v4 NAT at the boundary.
>> No new mangling code is needed. From the v4 point of view this
>> is bog standard NAPT with configured port mapping.
> 
> So if you're an IPv4 client and I'm an IPv6 server with address
> 2001:db8:31::1, what do you put in the destination address of the IPv4
> packets you send to me?

The public address of the NAT to which you are tunneling. Of course,
that NAT has to be configured to forward port N through a tunnel
to whatever IPv4 address 2001:db8:31::1 has borrowed.

(draft-despres-v6ops-apbp-00.txt would automate the borrowing
process, if you don't want to configure it.)

This doesn't get rid of NAPT nastiness for supporting servers.
But if someone insists on running a server for IPv4 clients that
doesn't have its own public IPv4 address, that nastiness is
intrinsic. The question is what's the simplest way to deal
with it.

    Brian





From owner-v6ops@ops.ietf.org  Tue Jun 17 23:40:57 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 30BA63A68A4
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 23:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.495
X-Spam-Level: 
X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 qw+cNg082KnV
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 17 Jun 2008 23:40:55 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 8C37A3A67E7
	for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 23:40:55 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8rEN-000LJ6-7Y
	for v6ops-data@psg.com; Wed, 18 Jun 2008 06:33:19 +0000
Received: from [192.100.105.134] (helo=mgw-mx09.nokia.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <teemu.savolainen@nokia.com>)
	id 1K8rEJ-000LHg-9Y
	for v6ops@ops.ietf.org; Wed, 18 Jun 2008 06:33:17 +0000
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5I5w56f006980;
	Wed, 18 Jun 2008 01:33:03 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 18 Jun 2008 09:32:39 +0300
Received: from vaebe102.NOE.Nokia.com ([10.160.244.12]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 18 Jun 2008 09:32:38 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
Date: Wed, 18 Jun 2008 09:32:37 +0300
Message-ID: <DC237AE116C10E4C9AD162D6C2EE62FEDBCC8E@vaebe102.NOE.Nokia.com>
In-Reply-To: <CE37AC97-4B71-4C4B-8765-3C20E914332D@muada.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
Thread-Index: Aci977XNhLDtDPn3TIi4N5ObhdWlBgTHFjWA
References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> <DC237AE116C10E4C9AD162D6C2EE62FEBDC842@vaebe102.NOE.Nokia.com> <CE37AC97-4B71-4C4B-8765-3C20E914332D@muada.com>
From: <teemu.savolainen@nokia.com>
To: <iljitsch@muada.com>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 18 Jun 2008 06:32:38.0947 (UTC) FILETIME=[1A808730:01C8D10D]
X-Nokia-AV: Clean
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


 >The problem with IPv4-only applications in an IPv6 world is=20
>that there is no way to encode all possible IPv6 destinations=20
>into an IPv4 header. However, the case where the ultimate=20
>destination is also IPv4 and it's just the network in the=20
>middle that's IPv4 is much easier.

True, but I wonder if it is a required feature that IPv4-only
applications can connect to IPv6 destinations? I.e. if application has
to connect to IPv6-destinations, the application should be updated to
support IPv6. The more common case could be network operator to upgrade
the access network to IPv6 while applications & services could still
continue use IPv4 - in that case the IPv4 connectivity should be
provided over the IPv6 cloud.

>In a previous modified-nat-pt draft I wrote about the v4-v6-v4=20
>case where IPv4 clients sit behind a CPE or layer in the stack=20
>that translates their IPv4 packets into IPv6 packets using SIIT (=3D
>stateless) and then the resulting IPv6 packets flow through the same
>NAT64 translators that IPv6 hosts that want to talk to the=20
>IPv4 world also use.
>
>Expect to see a new or updated draft on this topic before Dublin.

I'm looking forward to it. We should have a solution available that
includes client side changes, as I believe those can be more efficient
e.g. in wireless systems than the "CPE" based solutions (if the "CPE" is
actually at the other side of the air interface).

>I'm currently looking at defining a new DHCPv6 option that would allow
>NAT464 devices/layers to discover the 96 upper bits used by=20
>the NAT64 translator. Would DHCPv6 be fast enough for your use case?

It would (and often needed anyway e.g. for DNS discovery).

Best regards,
=09
	Teemu



From owner-v6ops@ops.ietf.org  Wed Jun 18 05:04:11 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5047528C0F6
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 18 Jun 2008 05:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.275
X-Spam-Level: *
X-Spam-Status: No, score=1.275 tagged_above=-999 required=5 tests=[AWL=-0.375,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35,
	HELO_MISMATCH_DE=1.448, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3,
	RDNS_NONE=0.1]
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 6o+X337dAEom
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 18 Jun 2008 05:04:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 3B63328C100
	for <v6ops-archive@lists.ietf.org>; Wed, 18 Jun 2008 05:04:05 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8wGk-0006Vm-4g
	for v6ops-data@psg.com; Wed, 18 Jun 2008 11:56:06 +0000
Received: from [134.76.10.26] (helo=mailer.gwdg.de)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K8wGM-0006Sj-Vu
	for v6ops@ops.ietf.org; Wed, 18 Jun 2008 11:55:52 +0000
Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5])
	by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69)
	(envelope-from <niklas.neumann@cs.uni-goettingen.de>)
	id 1K8wG4-00073i-FO; Wed, 18 Jun 2008 13:55:24 +0200
Message-ID: <4858F7AC.7070709@cs.uni-goettingen.de>
Date: Wed, 18 Jun 2008 13:55:24 +0200
From: Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Organization: University of Goettingen
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?=
 <Jinmei_Tatuya@isc.org>
CC: v6ops@ops.ietf.org
Subject: Re: Router Solicitations
References: <484E4875.1040508@cs.uni-goettingen.de>	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>	 <48563881.2080103@cs.uni-goettingen.de>	 <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>	 <48578C61.8080302@cs.uni-goettingen.de> <m2skvbyieq.wl%Jinmei_Tatuya@isc.org>
In-Reply-To: <m2skvbyieq.wl%Jinmei_Tatuya@isc.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: (clean) by exiscan+sophie
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Thank you all for your answers. If I have more follow-up questions I 
will post to the 6man list.

The background were just some theoretical considerations that we made 
about the IPv6 autoconfiguration and its "durability".
The basic question was if a host would try to keep an address when using 
the autoconfiguration. To be precise: If it would would keep using a 
previously assigned address as its unicast source address in Router 
Solicitation requests even after being disconnected from and then 
reconnected to a link (or switched off and back on).
Compared to DHCP for example were the servers usually reassign the same 
IP-Address to hosts. I know that with IPv6 nobody will care about 
IP-Addresses so much anymore but if they are somewhat persistent with 
the autoconfiguration they would still provide some recognizability.


Best regards
   Niklas

JINMEI Tatuya / 神明�哉 wrote:
> At Tue, 17 Jun 2008 12:05:21 +0200,
> Niklas Neumann <niklas.neumann@cs.uni-goettingen.de> wrote:
> 
>>>> Thank you for your response. Just to make it perfectly clear to me:
>>>> How long is a unicast address valid?
>>> Until its valid lifetime expires.
>>>
>>>> - Until the host gets disconnected from the link?
>>>> - Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
>>>> - Some other trigger (e.g. L2 trigger)?
>> So link disconnection or other L2 triggers are not supposed to have any 
>> impact on the lifetime?
> 
> No.
> 
> I don't know why you're so much worrying about such corner cases.
> Maybe you have some specific implementation and/or situation in your
> mind where the interpretation of these points matter much.  As a
> separate followup indicated, you may want to explain your intended
> scenario.  Otherwise the discussion would be superficial (e.g. I can
> only say 'No' because it's the answer and I don't know the background
> intent of the question).
> 
> p.s. I've not noticed this thread has been sent to v6ops.  The 6man
> list (ipv6@ietf.org) would be a better place for this topic.
> 
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.


-- 
Niklas Neumann - University of Goettingen, Institute of Informatics
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-14419



From owner-v6ops@ops.ietf.org  Wed Jun 18 07:08:03 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2FB823A6A10
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 18 Jun 2008 07:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RDNS_NONE=0.1]
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 AOYMRTicl-6G
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 18 Jun 2008 07:08:02 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 60D0C3A6852
	for <v6ops-archive@lists.ietf.org>; Wed, 18 Jun 2008 07:08:02 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K8yGe-000Lpu-2W
	for v6ops-data@psg.com; Wed, 18 Jun 2008 14:04:08 +0000
Received: from [74.125.46.28] (helo=yw-out-2324.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <bboissin@gmail.com>)
	id 1K8yGV-000Loy-RP
	for v6ops@ops.ietf.org; Wed, 18 Jun 2008 14:04:06 +0000
Received: by yw-out-2324.google.com with SMTP id 9so175148ywe.71
        for <v6ops@ops.ietf.org>; Wed, 18 Jun 2008 07:03:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:cc:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references;
        bh=1rAOabtI/69hWQNw1BE/B2yqsvPo1hsMc8B1O65e2Cw=;
        b=Bo4PPv2ZTOZBKSX/h0/u0ZLXEWLD1b2OQsC2JMBSxGEJjSWCuQT+mFlbvfXu628jGC
         kuaASuwpvsV+N/KIkh1Oaj3ZA1ILGeUJF8nF1UsOm2VPHoNmqEAlPIHCTdOxDULjiFi6
         sgAUOAzKBVxjI94zL527w443DB/k3TuNyVkds=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=EH+niNzlAGWohVzFD3LjJKEhwrgUMDqCmsqmggHYIFQRyMTohiSdp0EdRLF/ATgLVi
         TQvhxxBy2mmtDwcg/z1F2QZxX7vAZmCFw5nqYJpHNFc2N1c1qrjZEuI1/3ZEOiRlSTKn
         WyklgNiQKBRLak0DpkE0KWBP1ApSzQD6Tdc4o=
Received: by 10.150.11.6 with SMTP id 6mr1170263ybk.11.1213797835008;
        Wed, 18 Jun 2008 07:03:55 -0700 (PDT)
Received: by 10.151.48.12 with HTTP; Wed, 18 Jun 2008 07:03:54 -0700 (PDT)
Message-ID: <40f323d00806180703y74112b59l64cb0aa935ad8d10@mail.gmail.com>
Date: Wed, 18 Jun 2008 16:03:54 +0200
From: "Benoit Boissinot" <bboissin@gmail.com>
To: "Niklas Neumann" <niklas.neumann@cs.uni-goettingen.de>
Subject: Re: Router Solicitations
Cc: "=?BIG5?B?SklOTUVJIFRhdHV5YSAvIK+rqfq5Rqt2?=" <Jinmei_Tatuya@isc.org>, 
	v6ops@ops.ietf.org
In-Reply-To: <4858F7AC.7070709@cs.uni-goettingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <484E4875.1040508@cs.uni-goettingen.de>
	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
	 <48563881.2080103@cs.uni-goettingen.de>
	 <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
	 <48578C61.8080302@cs.uni-goettingen.de>
	 <m2skvbyieq.wl%Jinmei_Tatuya@isc.org>
	 <4858F7AC.7070709@cs.uni-goettingen.de>
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Wed, Jun 18, 2008 at 1:55 PM, Niklas Neumann
<niklas.neumann@cs.uni-goettingen.de> wrote:
> Compared to DHCP for example were the servers usually reassign the same
> IP-Address to hosts. I know that with IPv6 nobody will care about
> IP-Addresses so much anymore but if they are somewhat persistent with the
> autoconfiguration they would still provide some recognizability.
>
>

During autoconfiguration, the IP address is usually constructed from
the MAC address. So for a given prefix
the address will be persistent (unless the MAC changes, do to a
hardware, or configuration change, which
should be quite rare).

regards,

Benoit



From owner-v6ops@ops.ietf.org  Wed Jun 18 12:27:09 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BACE128C0F3
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 18 Jun 2008 12:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.325
X-Spam-Level: 
X-Spam-Status: No, score=-99.325 tagged_above=-999 required=5
	tests=[AWL=0.075, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2,
	NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 yOmpmj6K9ZPe
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 18 Jun 2008 12:27:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id CAA1A3A6A32
	for <v6ops-archive@lists.ietf.org>; Wed, 18 Jun 2008 12:27:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K93A8-000Cj8-A3
	for v6ops-data@psg.com; Wed, 18 Jun 2008 19:17:44 +0000
Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <Jinmei_Tatuya@isc.org>)
	id 1K93A4-000Cgx-6J
	for v6ops@ops.ietf.org; Wed, 18 Jun 2008 19:17:42 +0000
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f])
	by mon.jinmei.org (Postfix) with ESMTP id E89DF33C2E;
	Wed, 18 Jun 2008 12:17:39 -0700 (PDT)
Date: Wed, 18 Jun 2008 12:17:39 -0700
Message-ID: <m2iqw6y2lo.wl%Jinmei_Tatuya@isc.org>
From:	 JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org>
To:	 Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
Cc:	 v6ops@ops.ietf.org
Subject: Re: Router Solicitations
In-Reply-To: <4858F7AC.7070709@cs.uni-goettingen.de>
References: <484E4875.1040508@cs.uni-goettingen.de>
	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>
	 <48563881.2080103@cs.uni-goettingen.de>
	 <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org>
	 <48578C61.8080302@cs.uni-goettingen.de>
	 <m2skvbyieq.wl%Jinmei_Tatuya@isc.org>
	 <4858F7AC.7070709@cs.uni-goettingen.de>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

At Wed, 18 Jun 2008 13:55:24 +0200,
Niklas Neumann <niklas.neumann@cs.uni-goettingen.de> wrote:

> Thank you all for your answers. If I have more follow-up questions I 
> will post to the 6man list.
> 
> The background were just some theoretical considerations that we made 
> about the IPv6 autoconfiguration and its "durability".
> The basic question was if a host would try to keep an address when using 
> the autoconfiguration. To be precise: If it would would keep using a 
> previously assigned address as its unicast source address in Router 
> Solicitation requests even after being disconnected from and then 
> reconnected to a link (or switched off and back on).
> Compared to DHCP for example were the servers usually reassign the same 
> IP-Address to hosts. I know that with IPv6 nobody will care about 
> IP-Addresses so much anymore but if they are somewhat persistent with 
> the autoconfiguration they would still provide some recognizability.

The key is to perform DAD whenever the address you're going to use may
have been (validly) used by someone else.  In that sense there's
nothing special for addresses configured via stateless
autoconfiguration (the discussion equally applies to addresses
obtained via DHCPv6 and ones manually configured).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.



From owner-v6ops@ops.ietf.org  Thu Jun 19 07:58:42 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A25A53A6A09
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 19 Jun 2008 07:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.29
X-Spam-Level: 
X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.108,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 LIIhl-gu1wOA
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 19 Jun 2008 07:58:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 94EF33A68DE
	for <v6ops-archive@lists.ietf.org>; Thu, 19 Jun 2008 07:58:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9LOl-000MV0-Dv
	for v6ops-data@psg.com; Thu, 19 Jun 2008 14:46:03 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K9LOU-000MTj-5p
	for v6ops@ops.ietf.org; Thu, 19 Jun 2008 14:45:57 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id C16813EA121;
	Thu, 19 Jun 2008 16:45:44 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 6B9373EA0FC;
	Thu, 19 Jun 2008 16:45:44 +0200 (CEST)
Message-ID: <485A7117.4090206@free.fr>
Date: Thu, 19 Jun 2008 16:45:43 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Marcelo Bagnulo <marcelo@it.uc3m.es>
CC: v6ops <v6ops@ops.ietf.org>, Fred Baker <fred@cisco.com>
Subject: How to include APBP scenarios in the Coexistence Requirement I-D
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi Marcello,

You may not remember my e-mail of may 22:
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00808.html,

It dealt with the relationship between
- my draft-despres-v6ops-apbp-00 (APBP)
- your draft-ietf-v6ops-nat64-pb-statement-req-00

Since the matter of the APBP I-D fits in the scope of your Requirement 
I-D, I take the opportunity of a reminder to (hopefully) clarify the 
subject.


Your Requirement draft is about
  "IPv4/IPv6 Coexistence and Transition: Requirements for solutions".
Its scope, defined in the introduction, is:
  "requirements for solutions to IPv4/IPv6 coexistence and eventual
transition in a scenario in which dual stack operation is not the norm"
It includes, among others, scenarios for:
A. "an IPv4 system connecting to an IPv4 system across an IPv6
network"
B. "an IPv6 system connecting to an IPv4 system".

Now, in the APBP draft:
- Section 2 introduces a new scenario for A.
- Section 5.2 introduces a new scenario for a variant of B (where the
IPv6 system is modified to obtain E2E IPv4 transparency for IPv4/IPv6
encapsulated packets)

The purpose of these new scenarios is:
- Scalability (scenario A)
- E2E transparency (scenario B)


To introduce visibility of these scenarios in your draft without too 
much reorganization, I suggest this possibility:

In your I-D,
  " 2.1.2 Scenarios that do not require translation
    2.1.3 Scenarios that require translation "
would be replaced by:
  " 2.1.2 Scenarios that do not require translation between IPv6 and IPv4
      2.1.2.1 Scenarios based only on tunnels
              <current 2.1.2 text>
      2.1.2.1 Scenarios combining tunnels and address-port borrowing
	     < A text, not too long, I could volunteer to provide >
    2.1.3 Scenarios that require translation between IPv6 and IPv4
              <current 2.1.3 text > "


The questions are then:
- Is it agreed that something needs to be done? (And if not, what 
objections need to be discussed)
- If it is agreed, are there better ways to include APBP scenarios in 
the Requirement I-D?


Regards.

Rémi




From owner-v6ops@ops.ietf.org  Thu Jun 19 09:03:15 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id AEFB53A6927
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 19 Jun 2008 09:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5
	tests=[AWL=-0.661, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4,
	RDNS_NONE=0.1]
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 5JR7VXQlm1J5
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 19 Jun 2008 09:03:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id AFD993A69C9
	for <v6ops-archive@lists.ietf.org>; Thu, 19 Jun 2008 09:01:33 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9MUw-0005di-BF
	for v6ops-data@psg.com; Thu, 19 Jun 2008 15:56:30 +0000
Received: from [163.117.176.131] (helo=smtp01.uc3m.es)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <marcelo@it.uc3m.es>)
	id 1K9MUq-0005ck-MT
	for v6ops@ops.ietf.org; Thu, 19 Jun 2008 15:56:27 +0000
Received: from marcelo-bagnulos-macbook-pro.local 
	(74.pool85-53-142.dynamic.orange.es [85.53.142.74])by smtp01.uc3m.es 
	(Postfix) with ESMTP id D6DAE6EEBEF;Thu, 19 Jun 2008 17:56:21 +0200 (CEST)
Message-ID: <485A819B.6010900@it.uc3m.es>
Date: Thu, 19 Jun 2008 17:56:11 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
CC: v6ops <v6ops@ops.ietf.org>,
	Fred Baker <fred@cisco.com>
Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D
References: <485A7117.4090206@free.fr>
In-Reply-To: <485A7117.4090206@free.fr>
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-10.2685 TC:1F TRN:41 TV:5.5.1026(15982.000)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Remi,

as editor of the document, my task is to reflect the WG consensus in the 
document.
So far, i only see you supporting for this i.e. i haven't received any 
other comment on this respect.

So, if other people care to comment on this, and the WG express that 
they are ok with including this in the document, i would do that.

Regards, marcelo


Rémi Després escribió:
> Hi Marcello,
>
> You may not remember my e-mail of may 22:
> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00808.html,
>
> It dealt with the relationship between
> - my draft-despres-v6ops-apbp-00 (APBP)
> - your draft-ietf-v6ops-nat64-pb-statement-req-00
>
> Since the matter of the APBP I-D fits in the scope of your Requirement 
> I-D, I take the opportunity of a reminder to (hopefully) clarify the 
> subject.
>
>
> Your Requirement draft is about
>  "IPv4/IPv6 Coexistence and Transition: Requirements for solutions".
> Its scope, defined in the introduction, is:
>  "requirements for solutions to IPv4/IPv6 coexistence and eventual
> transition in a scenario in which dual stack operation is not the norm"
> It includes, among others, scenarios for:
> A. "an IPv4 system connecting to an IPv4 system across an IPv6
> network"
> B. "an IPv6 system connecting to an IPv4 system".
>
> Now, in the APBP draft:
> - Section 2 introduces a new scenario for A.
> - Section 5.2 introduces a new scenario for a variant of B (where the
> IPv6 system is modified to obtain E2E IPv4 transparency for IPv4/IPv6
> encapsulated packets)
>
> The purpose of these new scenarios is:
> - Scalability (scenario A)
> - E2E transparency (scenario B)
>
>
> To introduce visibility of these scenarios in your draft without too 
> much reorganization, I suggest this possibility:
>
> In your I-D,
>  " 2.1.2 Scenarios that do not require translation
>    2.1.3 Scenarios that require translation "
> would be replaced by:
>  " 2.1.2 Scenarios that do not require translation between IPv6 and IPv4
>      2.1.2.1 Scenarios based only on tunnels
>              <current 2.1.2 text>
>      2.1.2.1 Scenarios combining tunnels and address-port borrowing
>          < A text, not too long, I could volunteer to provide >
>    2.1.3 Scenarios that require translation between IPv6 and IPv4
>              <current 2.1.3 text > "
>
>
> The questions are then:
> - Is it agreed that something needs to be done? (And if not, what 
> objections need to be discussed)
> - If it is agreed, are there better ways to include APBP scenarios in 
> the Requirement I-D?
>
>
> Regards.
>
> Rémi
>
>




From owner-v6ops@ops.ietf.org  Thu Jun 19 09:26:42 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id ED3663A68CF
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 19 Jun 2008 09:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.306
X-Spam-Level: 
X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.092,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 m0juKa49w7nX
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 19 Jun 2008 09:26:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 12AC63A67E4
	for <v6ops-archive@lists.ietf.org>; Thu, 19 Jun 2008 09:26:42 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9MxC-000BSf-9h
	for v6ops-data@psg.com; Thu, 19 Jun 2008 16:25:42 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K9Mx2-000BPV-9N
	for v6ops@ops.ietf.org; Thu, 19 Jun 2008 16:25:37 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 95C5E3EA0C5;
	Thu, 19 Jun 2008 18:25:31 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 508BC3EA124;
	Thu, 19 Jun 2008 18:25:31 +0200 (CEST)
Message-ID: <485A887A.4020200@free.fr>
Date: Thu, 19 Jun 2008 18:25:30 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: teemu.savolainen@nokia.com
CC: iljitsch@muada.com, v6ops@ops.ietf.org
Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt
References: <20080513233001.301873A6854@core3.amsl.com> <482B5E3C.5000302@it.uc3m.es> <DC237AE116C10E4C9AD162D6C2EE62FEBDC842@vaebe102.NOE.Nokia.com> <CE37AC97-4B71-4C4B-8765-3C20E914332D@muada.com> <DC237AE116C10E4C9AD162D6C2EE62FEDBCC8E@vaebe102.NOE.Nokia.com>
In-Reply-To: <DC237AE116C10E4C9AD162D6C2EE62FEDBCC8E@vaebe102.NOE.Nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

teemu.savolainen@nokia.com  - Le 6/18/08 8:32 AM :
> ... I wonder if it is a required feature that IPv4-only
> applications can connect to IPv6 destinations? I.e. if application has
> to connect to IPv6-destinations, the application should be updated to
> support IPv6.

I share this view, and believe the point is important.

- On one hand, scenarios where a v4-only host connects to a v6-only host 
do raise ineresting problems from a theoretical point of view.

- But on the other hand, IETF suggesting that solutions to these 
problems should be deployed would be a disincentive to the 
generalization of v4&v6, in both Hosts and applications. This IMO would 
be a step backward.


Rémi



From owner-v6ops@ops.ietf.org  Thu Jun 19 10:56:01 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4CE503A6995
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 19 Jun 2008 10:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.317
X-Spam-Level: 
X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.081,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 otBx5glzJvnd
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 19 Jun 2008 10:56:00 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 66ABB3A68C2
	for <v6ops-archive@lists.ietf.org>; Thu, 19 Jun 2008 10:56:00 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9OG0-000N8H-Cm
	for v6ops-data@psg.com; Thu, 19 Jun 2008 17:49:12 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K9OFm-000N6d-Pk
	for v6ops@ops.ietf.org; Thu, 19 Jun 2008 17:49:09 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id B4DD33EA0AC;
	Thu, 19 Jun 2008 19:48:55 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 2A6A73EA0DF;
	Thu, 19 Jun 2008 19:48:54 +0200 (CEST)
Message-ID: <485A9C04.90808@free.fr>
Date: Thu, 19 Jun 2008 19:48:52 +0200
From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
CC: v6ops <v6ops@ops.ietf.org>
Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D
References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es>
In-Reply-To: <485A819B.6010900@it.uc3m.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

marcelo bagnulo braun  - Le 6/19/08 5:56 PM :
> Remi,
> 
> as editor of the document, my task is to reflect the WG consensus in the 
> document.

Fair enough.

> So far, i only see you supporting for this i.e. i haven't received any 
> other comment on this respect.
 >
> So, if other people care to comment on this, and the WG express that 
> they are ok with including this in the document, i would do that.

Please remember what Teemu Savolainen wrote to you in
http://psg.com/lists/v6ops/v6ops.2008/msg00800.html, namely:

"One aspect on these transition mechanisms is placement of NAT(s) (4-4, 
4-6, 6-4) and required ALGs, i.e. whether those are on client itself, on 
gateway, or nowhere (APBP kind of approach). Different approaches have 
different pros and cons, which should be studied more. The placement 
likely affects at least on scalability of the solution."



Also you can note what Brian Carpenter answered to Iljitsch van Beijnum, 
in http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html, namely:

 > The public address of the NAT to which you are tunneling. Of course,
 > that NAT has to be configured to forward port N through a tunnel
 > to whatever IPv4 address 2001:db8:31::1 has borrowed.
 >
 > (draft-despres-v6ops-apbp-00.txt would automate the borrowing
 > process, if you don't want to configure it.)

Automating configuration is of course a nice thing to have.



Rémi





From owner-v6ops@ops.ietf.org  Thu Jun 19 11:01:02 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EA90D3A6995
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 19 Jun 2008 11:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5
	tests=[AWL=-0.617, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4,
	RDNS_NONE=0.1]
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 p6lVOhifO-Vk
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 19 Jun 2008 11:01:02 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id F365A3A697D
	for <v6ops-archive@lists.ietf.org>; Thu, 19 Jun 2008 11:01:01 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9OQQ-000Ofl-9r
	for v6ops-data@psg.com; Thu, 19 Jun 2008 17:59:58 +0000
Received: from [163.117.176.133] (helo=smtp03.uc3m.es)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <marcelo@it.uc3m.es>)
	id 1K9OQB-000Odi-3h
	for v6ops@ops.ietf.org; Thu, 19 Jun 2008 17:59:55 +0000
Received: from marcelo-bagnulos-macbook-pro.local 
	(74.pool85-53-142.dynamic.orange.es [85.53.142.74])by smtp03.uc3m.es 
	(Postfix) with ESMTP id AA5D03F039D;Thu, 19 Jun 2008 19:59:40 +0200 (CEST)
Message-ID: <485A9E8C.8080907@it.uc3m.es>
Date: Thu, 19 Jun 2008 19:59:40 +0200
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
CC: v6ops <v6ops@ops.ietf.org>
Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D
References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> 
	<485A9C04.90808@free.fr>
In-Reply-To: <485A9C04.90808@free.fr>
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: 8bit
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-14.8415 TC:1F TRN:35 TV:5.5.1026(15982.000)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

In the next version, i will try to reflect the received comments indeed


Rémi Després escribió:
> marcelo bagnulo braun  - Le 6/19/08 5:56 PM :
>> Remi,
>>
>> as editor of the document, my task is to reflect the WG consensus in 
>> the document.
>
> Fair enough.
>
>> So far, i only see you supporting for this i.e. i haven't received 
>> any other comment on this respect.
> >
>> So, if other people care to comment on this, and the WG express that 
>> they are ok with including this in the document, i would do that.
>
> Please remember what Teemu Savolainen wrote to you in
> http://psg.com/lists/v6ops/v6ops.2008/msg00800.html, namely:
>
> "One aspect on these transition mechanisms is placement of NAT(s) 
> (4-4, 4-6, 6-4) and required ALGs, i.e. whether those are on client 
> itself, on gateway, or nowhere (APBP kind of approach). Different 
> approaches have different pros and cons, which should be studied more. 
> The placement likely affects at least on scalability of the solution."
>
>
>
> Also you can note what Brian Carpenter answered to Iljitsch van 
> Beijnum, in 
> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html, namely:
>
> > The public address of the NAT to which you are tunneling. Of course,
> > that NAT has to be configured to forward port N through a tunnel
> > to whatever IPv4 address 2001:db8:31::1 has borrowed.
> >
> > (draft-despres-v6ops-apbp-00.txt would automate the borrowing
> > process, if you don't want to configure it.)
>
> Automating configuration is of course a nice thing to have.
>
>
>
> Rémi
>
>
>




From owner-v6ops@ops.ietf.org  Thu Jun 19 15:04:14 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7A6103A697D
	for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 19 Jun 2008 15:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.502
X-Spam-Level: *
X-Spam-Status: No, score=1.502 tagged_above=-999 required=5 tests=[AWL=-1.502,
	FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6,
	MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 yhxJwH0SEQkz
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Thu, 19 Jun 2008 15:04:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 0F68E3A68BD
	for <v6ops-archive@lists.ietf.org>; Thu, 19 Jun 2008 15:04:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9S5A-0002h7-9M
	for v6ops-data@psg.com; Thu, 19 Jun 2008 21:54:16 +0000
Received: from [209.85.198.225] (helo=rv-out-0506.google.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <brian.e.carpenter@gmail.com>)
	id 1K9S56-0002gf-Tk
	for v6ops@ops.ietf.org; Thu, 19 Jun 2008 21:54:14 +0000
Received: by rv-out-0506.google.com with SMTP id b25so8219053rvf.41
        for <v6ops@ops.ietf.org>; Thu, 19 Jun 2008 14:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :organization:user-agent:mime-version:to:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=p9/7f0gd8tUNPcwlCEKBTNIjqjIqnCSHvlYI8yApfGU=;
        b=q5cvkEJPFcbfXXAmRNhQeyGPKOTZb1pIk2lWWBJl/YsbMTYWtRV77jara4AMA8aO0x
         T61wT8juxhSl5u//1nmfhvw6DQLhMPsBV35JDRj4hdcRXIlfiRsJdBzsUM7pzeEy4eTU
         S7BC1Rlda96h0SoRLPwLhQA3DS40T+xDQKDGE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=Z05eHxylmjUFzv630CsNuTI8oaaYmkxcavHGGAB/4UBt731RpVvsSXdWutII8a5nr6
         /G8XX6UIUsqmbVOC4a/7oaptz2F21Ae9ZiSPkBMABe6A7N+Aka2PjUM9UQMinvvAO9RC
         0+03SkY++lv4qgxbzStFBX++CRZoH7nypkc8Q=
Received: by 10.140.188.10 with SMTP id l10mr7070514rvf.6.1213912452623;
        Thu, 19 Jun 2008 14:54:12 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124])
        by mx.google.com with ESMTPS id k41sm2011506rvb.3.2008.06.19.14.54.11
        (version=SSLv3 cipher=RC4-MD5);
        Thu, 19 Jun 2008 14:54:12 -0700 (PDT)
Message-ID: <485AD581.40202@gmail.com>
Date: Fri, 20 Jun 2008 09:54:09 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= <remi.despres@free.fr>
CC: marcelo bagnulo braun <marcelo@it.uc3m.es>, 
 v6ops <v6ops@ops.ietf.org>
Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D
References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr>
In-Reply-To: <485A9C04.90808@free.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


>> (draft-despres-v6ops-apbp-00.txt would automate the borrowing
>> process, if you don't want to configure it.)

There's also draft-cheshire-nat-pmp of course. I think
this can be included as an open question in the requirements
draft, and the discussion is probably broader than just v6ops.

   Brian



From owner-v6ops@ops.ietf.org  Fri Jun 20 00:23:56 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2B75B3A6983
	for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 20 Jun 2008 00:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.061
X-Spam-Level: **
X-Spam-Status: No, score=2.061 tagged_above=-999 required=5
	tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35,
	J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 P0w0AMKKnoY2
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Fri, 20 Jun 2008 00:23:55 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 4A9713A6943
	for <v6ops-archive@lists.ietf.org>; Fri, 20 Jun 2008 00:23:55 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9ar5-00069Y-CT
	for v6ops-data@psg.com; Fri, 20 Jun 2008 07:16:19 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <remi.despres@free.fr>)
	id 1K9ar1-00068w-DJ
	for v6ops@ops.ietf.org; Fri, 20 Jun 2008 07:16:17 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1])
	by smtp4-g19.free.fr (Postfix) with ESMTP id 7AF7F3EA0E7;
	Fri, 20 Jun 2008 09:16:14 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144])
	by smtp4-g19.free.fr (Postfix) with ESMTP id A49693EA0D7;
	Fri, 20 Jun 2008 09:16:13 +0200 (CEST)
Message-ID: <485B593B.9080209@free.fr>
Date: Fri, 20 Jun 2008 09:16:11 +0200
From: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: v6ops <v6ops@ops.ietf.org>
Subject: Re: How to include APBP scenarios in the Coexistence RequirementI-D
References: <485A7117.4090206@free.fr> <485A819B.6010900@it.uc3m.es> <485A9C04.90808@free.fr> <485AD581.40202@gmail.com>
In-Reply-To: <485AD581.40202@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Brian E Carpenter  - Le 6/19/08 11:54 PM :

> There's also draft-cheshire-nat-pmp of course. I think
> this can be included as an open question in the requirements
> draft, and the discussion is probably broader than just v6ops.

Thanks a lot.
I had missed this important one!

Its scope does differ from that of APBP in that:
- its NAT-PMP deals with port mappings *in NAT devices*
- APBP deals with address-port borrowing from APBP servers where *NATs 
are avoided* (IPv4 packets can be just encapsulated and decapsulated).

I plan to study the NAT-PMP draft in details, and hopefully identify how 
much of it can be extended or adapted to the scope of APBP.

Where a "broader" discussion could start is an interesting question.
So far, v6ops seemed to me the best fit, but any other decision would be 
fine.


Regards.

Rémi



From owner-v6ops@ops.ietf.org  Fri Jun 20 12:29:51 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 442763A6886
	for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 20 Jun 2008 12:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level: 
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5
	tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 xlbNrihKnmOO
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Fri, 20 Jun 2008 12:29:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id B40783A684D
	for <v6ops-archive@lists.ietf.org>; Fri, 20 Jun 2008 12:28:27 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1K9m9i-000450-29
	for v6ops-data@psg.com; Fri, 20 Jun 2008 19:20:18 +0000
Received: from [198.24.6.9] (helo=imr1.ericy.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <suresh.krishnan@ericsson.com>)
	id 1K9m9L-00042t-WD
	for v6ops@ops.ietf.org; Fri, 20 Jun 2008 19:20:06 +0000
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m5KJJaxs016616;
	Fri, 20 Jun 2008 14:19:36 -0500
Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 20 Jun 2008 14:19:56 -0500
Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 20 Jun 2008 14:19:56 -0500
Message-ID: <485C0304.5000508@ericsson.com>
Date: Fri, 20 Jun 2008 15:20:36 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Niklas Neumann <niklas.neumann@cs.uni-goettingen.de>
CC: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?=
 <Jinmei_Tatuya@isc.org>,
        v6ops@ops.ietf.org
Subject: Re: Router Solicitations
References: <484E4875.1040508@cs.uni-goettingen.de>	 <m2zlpqtdk7.wl%Jinmei_Tatuya@isc.org>	 <48563881.2080103@cs.uni-goettingen.de> <m2wskpgl9j.wl%Jinmei_Tatuya@isc.org> <48578C61.8080302@cs.uni-goettingen.de>
In-Reply-To: <48578C61.8080302@cs.uni-goettingen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 20 Jun 2008 19:19:56.0583 (UTC) FILETIME=[9FE5CB70:01C8D30A]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi Niklas,

Niklas Neumann wrote:
> JINMEI Tatuya / 神明�哉 wrote:
>>> Thank you for your response. Just to make it perfectly clear to me:
>>> How long is a unicast address valid?
>>
>> Until its valid lifetime expires.
>>
>>> - Until the host gets disconnected from the link?
>>> - Until some timeout expires (e.g. Router Lifetime, DHCP Lifetime)?
>>> - Some other trigger (e.g. L2 trigger)?
> 
> So link disconnection or other L2 triggers are not supposed to have any 
> impact on the lifetime?

This really depends on the implementation you are talking about. If you 
are talking about a standard RFC4861/RFC4862 compliant node, it does not 
make a difference. But there is work ongoing in the ietf to change this. 
e.g. We are working in the dna working group to come up with a solution 
that updates standard neighbor discovery. In the dna solution, an L2 
trigger invalidates the address until it is verified to be still usable.
You can check out RFC4957 and 
http://tools.ietf.org/html/draft-ietf-dna-simple-00 if you would like 
more info on this work.

Thanks
Suresh




From c_jedra@nadarzyn.net.pl  Sat Jun 21 16:56:45 2008
Return-Path: <c_jedra@nadarzyn.net.pl>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6BA043A695B;
	Sat, 21 Jun 2008 16:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -62.894
X-Spam-Level: 
X-Spam-Status: No, score=-62.894 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597,
	FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,
	FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357,
	HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129,
	RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877,
	RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931,
	USER_IN_WHITELIST=-100]
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 kjTHYn4a5UW4; Sat, 21 Jun 2008 16:56:44 -0700 (PDT)
Received: from 201-236-157-90.adsl.tie.cl (201-236-157-90.adsl.tie.cl [201.236.157.90])
	by core3.amsl.com (Postfix) with SMTP id 656333A6958;
	Sat, 21 Jun 2008 16:56:39 -0700 (PDT)
X-Originating-IP: 106.192.240.250 by smtp.201.236.157.90;  Sat, 21 Jun 2008 19:56:41 -0500
Message-ID: <gchvrkiEGDORTsmime-archive@megatron.ietf.org>
From: "Sadie Shelton" <smime-archive@megatron.ietf.org>
Reply-To: "Sadie Shelton" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Replica watches make great gifts
Date: Sat, 21 Jun 2008 19:56:41 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable.
http://xuvodymexal70.blogspot.com/

As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today!
http://xuvodymexal70.blogspot.com/





From owner-v6ops@ops.ietf.org  Sun Jun 22 22:30:43 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 355393A6880
	for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 22 Jun 2008 22:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.441
X-Spam-Level: 
X-Spam-Status: No, score=0.441 tagged_above=-999 required=5
	tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
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 xaajkSJGbV2B
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Sun, 22 Jun 2008 22:30:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 3E9523A67A6
	for <v6ops-archive@lists.ietf.org>; Sun, 22 Jun 2008 22:30:39 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KAeUd-000LR4-7E
	for v6ops-data@psg.com; Mon, 23 Jun 2008 05:21:31 +0000
Received: from [74.53.155.170] (helo=wibble.focb.co.nz)
	by psg.com with smtp (Exim 4.69 (FreeBSD))
	(envelope-from <davidm@thetiger.com>)
	id 1KAeUR-000LPs-6q
	for v6ops@ops.ietf.org; Mon, 23 Jun 2008 05:21:21 +0000
Received: (qmail 12433 invoked by uid 509); 23 Jun 2008 05:21:17 -0000
Received: from 74.53.155.170 by wibble.focb.co.nz (envelope-from <davidm@thetiger.com>, uid 89) with qmail-scanner-2.01 
 (clamdscan: 0.93.1/7531. spamassassin: 3.2.4.  
 Clear:RC:1(74.53.155.170):. 
 Processed in 0.041838 secs); 23 Jun 2008 05:21:17 -0000
Received: from wibble.focb.co.nz (74.53.155.170)
	by 0 with SMTP; Mon, 23 Jun 2008 00:21:17 -0500
Date: Mon, 23 Jun 2008 00:21:16 -0500 (CDT)
From: David Miles <davidm@thetiger.com>
X-X-Sender: davidm@wibble.focb.co.nz
To: v6ops@ops.ietf.org
Subject: Neighbor Discovery and on-link determination
Message-ID: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

I have seen an unusual scenario which I was wanting to run past people to 
comment on:

I have routerA and routerB connected to each other via Ethernet.

RouterA has the following addresses on the interface to RouterB:
2000:100::2/64
3000:100::2/64
With a default route to 2000:100::1

RouterB has the following addresses on the interface to RouterA:
2000:100::1/64
With a route for 3000:100::/64 to 2000:100::2

Per RFC4861, RouterA is sending ND as follows (assume it wants to 
src traffic from 3000:100::2 to a off-link address):
    3000:1::2 -> FF02::1:FF00:1
    Type: Neighbor Solicitation (135)
    Code: No Code (0)
       Tgt Addr: 2000:100::1
       Option  : Src Link Layer Addr 00:00:00:00:00:01

As 7.2.2 says "if the source address of the packet prompting the 
solicitation is the same as one of the addresses assigned to the outgoing 
interface, that address SHOULD be placed in the IP Source Address of the 
outgoing solicitation."

When RouterB will receive the ND as it is sent to the solicited-node MC 
address and will check the target address is valid (matches an addresss 
assigned to the receiving interface).
RouterB should then create a Neighbour Cache entry and set its state to 
STALE using the link-layer address in the ND. It should then send a 
solicited neighbor advertisement.

This means that the RouterB will have a single address 3000:1::2 in its 
Neighbour Cache, but the route will direct traffic to 2000:200::2. 
Obviously the Neighbour Cache would now contain an entry for an address 
that does not (appear) to be on-link from a route-table perspective.

How should Neighbour Cache and route table interact on a routerB? I had 
always assumed route table replaces Prefix List on a router, but that 
would mean Neighbour Cache would always be consulted with the next-hop of 
the static route (following the sending algorithm in RFC 4861).

This seems to directly relate to the definition of on-link as being:
- an address covered by on of the link's prefixes, or
- an address in the target of a rediect, or
- an address in the target of a neigbour advertisement, or
- an address in the source of a neighbour discovery message

Should a router really consider an address on-link just because it 
received a ND - I can see many potential security concerns if that is the 
case.

Any clarifications or experiance appreciated.

Regards,

-David Miles



From owner-v6ops@ops.ietf.org  Mon Jun 23 04:13:13 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 573113A67FB
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 23 Jun 2008 04:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,
	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 0WV2ghXRWHCi
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 23 Jun 2008 04:13:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 55EE73A68AC
	for <v6ops-archive@lists.ietf.org>; Mon, 23 Jun 2008 04:13:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KAjsz-0003vq-3A
	for v6ops-data@psg.com; Mon, 23 Jun 2008 11:07:01 +0000
Received: from [2001:fa8::25] (helo=mail.nttv6.net)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <arifumi@nttv6.net>)
	id 1KAjsv-0003vR-2H
	for v6ops@ops.ietf.org; Mon, 23 Jun 2008 11:06:59 +0000
Received: from arifumi1.nttv6.com (arifumi1.nttv6.com [192.47.163.61])
	by mail.nttv6.net (8.14.3/8.14.1) with ESMTP id m5NB6xFg001641
	for <v6ops@ops.ietf.org>; Mon, 23 Jun 2008 20:07:01 +0900 (JST)
	(envelope-from arifumi@nttv6.net)
Message-Id: <95E247E4-57DB-4BC2-B1B0-AFAF4337CD24@nttv6.net>
From: Arifumi Matsumoto <arifumi@nttv6.net>
To: v6ops@ops.ietf.org
Content-Type: text/plain; charset=ISO-2022-JP; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Fwd: New Version Notification for  draft-arifumi-6man-rfc3484-revise-00 
Date: Mon, 23 Jun 2008 20:06:43 +0900
References: <93D9EA01-9679-41A7-B62A-B1CEA622698F@nttv6.net>
X-Mailer: Apple Mail (2.924)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Mon, 23 Jun 2008 20:07:01 +0900 (JST)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Ops, let me re-send the following e-mail.

Kindest regards,

Begin forwarded message:

> $B:9=P?M(B: Arifumi Matsumoto <arifumi@nttv6.net>
> $BF|;~(B: 2008$BG/(B6$B7n(B23$BF|(B 18:50:21:JST
> $B08@h(B: ipv6@ietf.org
> Cc: ietf@ietf.org, v6ops@ietf.org
> $B7oL>(B: Fwd: New Version Notification for  draft-arifumi-6man- 
> rfc3484-revise-00
>
> Folks,
>
> I submitted the following draft regarding RFC 3484 revision.
> This draft covers these issues:
>
> - to remove the description regarding site-local unicast address.
> - ULA related changes, such as the default policy table.
> - to disable the rule 9 of the destination address selection rules.
>  i.e. the longest matching rule.
>
> Though we had discussion regarding the longest matching rule at
> several places like ietf@ietf.org and v6ops@ietf.org, why not
> discuss at 6man to start ?
>
> Any comments are welcome.
>
> Begin forwarded message:
>
>> $B:9=P?M(B: IETF I-D Submission Tool <idsubmission@ietf.org>
>> $BF|;~(B: 2008$BG/(B6$B7n(B19$BF|(B 18:40:27:JST
>> $B08@h(B: arifumi@nttv6.net
>> Cc: fujisaki@syce.net, hiromi@inetcore.com, kanayama_kenichi@intec-si.co.jp
>> $B7oL>(B: New Version Notification for  draft-arifumi-6man-rfc3484- 
>> revise-00
>>
>>
>> A new version of I-D, draft-arifumi-6man-rfc3484-revise-00.txt has  
>> been successfuly submitted by Arifumi Matsumoto and posted to the  
>> IETF repository.
>>
>> Filename:	 draft-arifumi-6man-rfc3484-revise
>> Revision:	 00
>> Title:		 Things To Be Considered for RFC 3484 Revision
>> Creation_date:	 2008-06-19
>> WG ID:		 Independent Submission
>> Number_of_pages: 10
>>
>> Abstract:
>> RFC 3484 has several known issues to be fixed mainly because of the
>> deprecation of IPv6 site-local unicast address and the coming of ULA.
>> Additionally, the rule 9 of the destination address selection rules,
>> namely the longest matching rule, is known for its adverse effect on
>> the round robin DNS technique.  This document covers these essential
>> points to be modified and proposes possible useful changes to be
>> included in the revision of RFC 3484.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>


--
$B>>K\(B $BB8;K(B <arifumi@nttv6.net>
  NTT$B>pJsN.DL%W%i%C%H%U%)!<%`8&5f=j(B
  $B%;%-%e%"%3%_%e%K%1!<%7%g%s4pHW%W%m%8%'%/%H(B
  $B")(B180-8585 $BEl5~ETIpB"Ln;TNPD.(B3-9-11
  TEL: 0422-59-3334 / FAX: 0422-59-5637




From c_kusickova.jaroslava@feifer.cz  Mon Jun 23 10:25:43 2008
Return-Path: <c_kusickova.jaroslava@feifer.cz>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 419053A69CE;
	Mon, 23 Jun 2008 10:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -80.175
X-Spam-Level: 
X-Spam-Status: No, score=-80.175 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597,
	FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999,
	HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96,
	RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100]
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 nJCsNw4PCuxw; Mon, 23 Jun 2008 10:25:42 -0700 (PDT)
Received: from pc-251-108-46-190.cm.vtr.net (pc-251-108-46-190.cm.vtr.net [190.46.108.251])
	by core3.amsl.com (Postfix) with SMTP id 1FAA13A69B6;
	Mon, 23 Jun 2008 10:25:23 -0700 (PDT)
X-Originating-IP: 247.102.72.100 by smtp.190.46.108.251;  Mon, 23 Jun 2008 13:25:22 -0500
Message-ID: <dwsvrlOFYCFTuser@ietf.org>
From: "Rachelle Cabrera" <user@ietf.org>
Reply-To: "Rachelle Cabrera" <user@ietf.org>
To: user@ietf.org
Subject: Spring quality watches offer
Date: Mon, 23 Jun 2008 13:25:22 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200.
http://pohywugevym48.blogspot.com/

For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas.
http://pohywugevym48.blogspot.com/





From cabeseg@celebhotel.com  Tue Jun 24 02:18:35 2008
Return-Path: <cabeseg@celebhotel.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id AF65B3A68F7;
	Tue, 24 Jun 2008 02:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -72.469
X-Spam-Level: 
X-Spam-Status: No, score=-72.469 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357,
	HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5,
	RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
	RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	USER_IN_WHITELIST=-100]
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 dSKQLMA1947v; Tue, 24 Jun 2008 02:18:32 -0700 (PDT)
Received: from bl10-189-218.dsl.telepac.pt (bl10-189-218.dsl.telepac.pt [85.243.189.218])
	by core3.amsl.com (Postfix) with SMTP id 07CA63A67EB;
	Tue, 24 Jun 2008 02:18:15 -0700 (PDT)
X-Originating-IP: 245.96.198.176 by smtp.85.243.189.218;  Tue, 24 Jun 2008 05:18:09 -0500
Message-ID: <qtndqkMNWMUsmime-archive@megatron.ietf.org>
From: "Hung Shepherd" <smime-archive@megatron.ietf.org>
Reply-To: "Hung Shepherd" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Looking for a replica watch?
Date: Tue, 24 Jun 2008 05:18:09 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Did you watch the last 007 flick, Casino Royale? If you did, you probably noticed that all throughout the movie, James Bond wears an spectacularly beautiful Omega watch... and he even brags about it! How would you like to be wearing that same exact model watch? The good news is that YOU can! Because now, you don't have to spend thousands of dollars to sport an Omega watch! When you visit Diamond Replicas, you will be able to browse through dozens of Omega replica watches, and pick the one of your dreams for just a couple of hundred dollars. Our watches are of such undeniably high quality, and offer such superior performance, that you'll fall in love with them, and what's best: stay in love with them for years to come! Come inside Diamond Replicas and pick your new Omega today!
http://golacyteven31.blogspot.com/






From owner-v6ops@ops.ietf.org  Tue Jun 24 08:45:36 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5D69B3A6861
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 24 Jun 2008 08:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.495
X-Spam-Level: 
X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 Hg1LdHKhADVU
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 24 Jun 2008 08:45:25 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C502D3A67AA
	for <v6ops-archive@lists.ietf.org>; Tue, 24 Jun 2008 08:45:22 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KBAa2-000PKR-Mz
	for v6ops-data@psg.com; Tue, 24 Jun 2008 15:37:14 +0000
Received: from [32.97.182.146] (helo=e6.ny.us.ibm.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69 (FreeBSD))
	(envelope-from <narten@us.ibm.com>)
	id 1KBAZx-000PJU-2R
	for v6ops@ops.ietf.org; Tue, 24 Jun 2008 15:37:12 +0000
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m5OFdQbn031380
	for <v6ops@ops.ietf.org>; Tue, 24 Jun 2008 11:39:26 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5OFatHD219068
	for <v6ops@ops.ietf.org>; Tue, 24 Jun 2008 11:36:55 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5OFatF9019575
	for <v6ops@ops.ietf.org>; Tue, 24 Jun 2008 11:36:55 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-209-88.mts.ibm.com [9.65.209.88])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m5OFaqSJ019478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jun 2008 11:36:54 -0400
Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m5OFanr6005744;
	Tue, 24 Jun 2008 17:36:49 +0200
Message-Id: <200806241536.m5OFanr6005744@cichlid.raleigh.ibm.com>
To: David Miles <davidm@thetiger.com>
cc: v6ops@ops.ietf.org
Subject: Re: Neighbor Discovery and on-link determination
In-reply-to: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz>
References: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz>
Comments: In-reply-to David Miles <davidm@thetiger.com>
   message dated "Mon, 23 Jun 2008 00:21:16 -0500."
Date: Tue, 24 Jun 2008 17:36:49 +0200
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

David Miles <davidm@thetiger.com> writes:

> I have seen an unusual scenario which I was wanting to run past people to 
> comment on:

> I have routerA and routerB connected to each other via Ethernet.

> RouterA has the following addresses on the interface to RouterB:
> 2000:100::2/64
> 3000:100::2/64
> With a default route to 2000:100::1

> RouterB has the following addresses on the interface to RouterA:
> 2000:100::1/64
> With a route for 3000:100::/64 to 2000:100::2

> Per RFC4861, RouterA is sending ND as follows (assume it wants to 
> src traffic from 3000:100::2 to a off-link address):
>     3000:1::2 -> FF02::1:FF00:1
>     Type: Neighbor Solicitation (135)
>     Code: No Code (0)
>        Tgt Addr: 2000:100::1
>        Option  : Src Link Layer Addr 00:00:00:00:00:01

> As 7.2.2 says "if the source address of the packet prompting the 
> solicitation is the same as one of the addresses assigned to the outgoing 
> interface, that address SHOULD be placed in the IP Source Address of the 
> outgoing solicitation."

> When RouterB will receive the ND as it is sent to the solicited-node MC 
> address and will check the target address is valid (matches an addresss 
> assigned to the receiving interface).
> RouterB should then create a Neighbour Cache entry and set its state to 
> STALE using the link-layer address in the ND. It should then send a 
> solicited neighbor advertisement.

> This means that the RouterB will have a single address 3000:1::2 in its 
> Neighbour Cache, but the route will direct traffic to 2000:200::2. 
> Obviously the Neighbour Cache would now contain an entry for an address 
> that does not (appear) to be on-link from a route-table perspective.

Hmm. This would appear to be a bug.

I do not believe it was the intention to have any addresses that
appear as the source of an NS result in a recipient of the NS
concluding that the source address is on-link.

That said, if you follow the words in the spec (with the "conceptual
algorithms"), the result would appear to be a bogus entry in the
Neighbor Cache, but one that would not get used. I.e., when sending to
that destination, RouterB would first look in its Destination Cache,
find no entry and then do next-hop determination (i.e., by looking at
the on-link information. It would NOT look in the Neighbor Cache at
this point, it only does that after determining if the destination is
on-link.

In any case, I would have expected that before creating a Neighbor
Cache Entry for the source address mentioned above, the receiver
should first verify that the address would be considered on-link per
the standard checks.

> How should Neighbour Cache and route table interact on a routerB? I had 
> always assumed route table replaces Prefix List on a router, but that 
> would mean Neighbour Cache would always be consulted with the next-hop of 
> the static route (following the sending algorithm in RFC 4861).

That may be the common implementation, but that is not what the
conceptual sending alogrithm says should happen.

> This seems to directly relate to the definition of on-link as being:
> - an address covered by on of the link's prefixes, or
> - an address in the target of a rediect, or

yes

> - an address in the target of a neigbour advertisement, or

There is no definition that I know if that would allow you to draw
this conclusion. All one can conclude is that the sender of the NS
believes the target is on-link. They may be right, but they may also
be wrong.

> - an address in the source of a neighbour discovery message

No, per above.

> Should a router really consider an address on-link just because it 
> received a ND - I can see many potential security concerns if that is the 
> case.

I think not, with security concerns being one reason why not.

> Any clarifications or experiance appreciated.

Good catch!

Thomas



From owner-v6ops@ops.ietf.org  Tue Jun 24 17:11:20 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 243C73A67AB
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 24 Jun 2008 17:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.448
X-Spam-Level: 
X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6,
	RDNS_NONE=0.1]
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 x8dTmzQCLHC4
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue, 24 Jun 2008 17:11:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id A7D5F3A6A24
	for <v6ops-archive@lists.ietf.org>; Tue, 24 Jun 2008 17:11:18 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KBIV2-000Ozp-PP
	for v6ops-data@psg.com; Wed, 25 Jun 2008 00:04:36 +0000
Received: from [74.53.155.170] (helo=wibble.focb.co.nz)
	by psg.com with smtp (Exim 4.69 (FreeBSD))
	(envelope-from <davidm@thetiger.com>)
	id 1KBIUx-000Oyz-Jn
	for v6ops@ops.ietf.org; Wed, 25 Jun 2008 00:04:33 +0000
Received: (qmail 31110 invoked by uid 509); 25 Jun 2008 00:04:29 -0000
Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from <davidm@thetiger.com>, uid 89) with qmail-scanner-2.01 
 (clamdscan: 0.93.1/7546. spamassassin: 3.2.4.  
 Clear:RC:1(211.28.128.246):. 
 Processed in 0.059602 secs); 25 Jun 2008 00:04:29 -0000
Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246)
	by 0 with SMTP; Tue, 24 Jun 2008 19:04:28 -0500
Message-Id: <C93F5BD2-225F-493A-B8B9-E0BC28C94037@thetiger.com>
From: David Miles <davidm@thetiger.com>
To: Thomas Narten <narten@us.ibm.com>,
 IETF V6OPS WG <v6ops@ops.ietf.org>
In-Reply-To: <200806241536.m5OFanr6005744@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Neighbor Discovery and on-link determination
Date: Wed, 25 Jun 2008 10:04:25 +1000
References: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz> <200806241536.m5OFanr6005744@cichlid.raleigh.ibm.com>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Thanks Thomas,

I'll move this into v6man if that is the case (and to ensure everyone  
is across it).

So in summary, the definition of on-link is where the uncertainty  
arose, because the current definition is:
on-link - an address that is assigned to an interface on a specified  
link. A node considers an address to be on- link if:
- it is covered by one of the link's prefixes (e.g., as indicated by  
the on-link flag in the Prefix Information option), or
- a neighboring router specifies the address as the target of a  
Redirect message, or
- a Neighbor Advertisement message is received for the (target)  
address, or
- any Neighbor Discovery message is received from the address.


It sounds as though we should remove the last two conditions?

I'd also suggest that in the Message Validation section we include the  
checks you mention (is the source of the ND or target of the NA an on- 
link prefix per Prefix List)

Best Regards,

-David

On 25/06/2008, at 1:36 AM, Thomas Narten wrote:

> David Miles <davidm@thetiger.com> writes:
>
>> I have seen an unusual scenario which I was wanting to run past  
>> people to
>> comment on:
>
>> I have routerA and routerB connected to each other via Ethernet.
>
>> RouterA has the following addresses on the interface to RouterB:
>> 2000:100::2/64
>> 3000:100::2/64
>> With a default route to 2000:100::1
>
>> RouterB has the following addresses on the interface to RouterA:
>> 2000:100::1/64
>> With a route for 3000:100::/64 to 2000:100::2
>
>> Per RFC4861, RouterA is sending ND as follows (assume it wants to
>> src traffic from 3000:100::2 to a off-link address):
>>    3000:1::2 -> FF02::1:FF00:1
>>    Type: Neighbor Solicitation (135)
>>    Code: No Code (0)
>>       Tgt Addr: 2000:100::1
>>       Option  : Src Link Layer Addr 00:00:00:00:00:01
>
>> As 7.2.2 says "if the source address of the packet prompting the
>> solicitation is the same as one of the addresses assigned to the  
>> outgoing
>> interface, that address SHOULD be placed in the IP Source Address  
>> of the
>> outgoing solicitation."
>
>> When RouterB will receive the ND as it is sent to the solicited- 
>> node MC
>> address and will check the target address is valid (matches an  
>> addresss
>> assigned to the receiving interface).
>> RouterB should then create a Neighbour Cache entry and set its  
>> state to
>> STALE using the link-layer address in the ND. It should then send a
>> solicited neighbor advertisement.
>
>> This means that the RouterB will have a single address 3000:1::2 in  
>> its
>> Neighbour Cache, but the route will direct traffic to 2000:200::2.
>> Obviously the Neighbour Cache would now contain an entry for an  
>> address
>> that does not (appear) to be on-link from a route-table perspective.
>
> Hmm. This would appear to be a bug.
>
> I do not believe it was the intention to have any addresses that
> appear as the source of an NS result in a recipient of the NS
> concluding that the source address is on-link.
>
> That said, if you follow the words in the spec (with the "conceptual
> algorithms"), the result would appear to be a bogus entry in the
> Neighbor Cache, but one that would not get used. I.e., when sending to
> that destination, RouterB would first look in its Destination Cache,
> find no entry and then do next-hop determination (i.e., by looking at
> the on-link information. It would NOT look in the Neighbor Cache at
> this point, it only does that after determining if the destination is
> on-link.
>
> In any case, I would have expected that before creating a Neighbor
> Cache Entry for the source address mentioned above, the receiver
> should first verify that the address would be considered on-link per
> the standard checks.
>
>> How should Neighbour Cache and route table interact on a routerB? I  
>> had
>> always assumed route table replaces Prefix List on a router, but that
>> would mean Neighbour Cache would always be consulted with the next- 
>> hop of
>> the static route (following the sending algorithm in RFC 4861).
>
> That may be the common implementation, but that is not what the
> conceptual sending alogrithm says should happen.
>
>> This seems to directly relate to the definition of on-link as being:
>> - an address covered by on of the link's prefixes, or
>> - an address in the target of a rediect, or
>
> yes
>
>> - an address in the target of a neigbour advertisement, or
>
> There is no definition that I know if that would allow you to draw
> this conclusion. All one can conclude is that the sender of the NS
> believes the target is on-link. They may be right, but they may also
> be wrong.
>
>> - an address in the source of a neighbour discovery message
>
> No, per above.
>
>> Should a router really consider an address on-link just because it
>> received a ND - I can see many potential security concerns if that  
>> is the
>> case.
>
> I think not, with security concerns being one reason why not.
>
>> Any clarifications or experiance appreciated.
>
> Good catch!
>
> Thomas
>




From cabrioni@cabrioni.it  Tue Jun 24 21:28:54 2008
Return-Path: <cabrioni@cabrioni.it>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CDFD93A697F;
	Tue, 24 Jun 2008 21:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -75.462
X-Spam-Level: 
X-Spam-Status: No, score=-75.462 tagged_above=-999 required=5
	tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994,
	HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129,
	RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666,
	TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 DuZz9lsq24yP; Tue, 24 Jun 2008 21:28:54 -0700 (PDT)
Received: from 65-128-20-190.adsl.terra.cl (65-128-20-190.adsl.terra.cl [190.20.128.65])
	by core3.amsl.com (Postfix) with SMTP id 53D4E3A68D6;
	Tue, 24 Jun 2008 21:28:47 -0700 (PDT)
X-Originating-IP: 183.224.113.255 by smtp.190.20.128.65;  Wed, 25 Jun 2008 00:28:43 -0500
Message-ID: <sfeqqkMQLFPMtechspec@megatron.ietf.org>
From: "Lena Koch" <techspec@megatron.ietf.org>
Reply-To: "Lena Koch" <techspec@megatron.ietf.org>
To: techspec@megatron.ietf.org
Subject: Classic timepieces replicas
Date: Wed, 25 Jun 2008 00:28:43 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200.
http://www.geocities.com/warnerzyvuxy

For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas.
http://www.geocities.com/warnerzyvuxy




No virus found in this outgoing message
Checked by PC Tools AntiVirus (4.0.0.26 - 10.063.005).
http://www.pctools.com/free-antivirus/


From owner-v6ops@ops.ietf.org  Wed Jun 25 03:42:24 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A80223A6A68
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 25 Jun 2008 03:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.495
X-Spam-Level: 
X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1]
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 TtPFKnjDvyJr
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 25 Jun 2008 03:42:23 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id A09823A6A57
	for <v6ops-archive@lists.ietf.org>; Wed, 25 Jun 2008 03:42:23 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KBSLh-0008Bq-QJ
	for v6ops-data@psg.com; Wed, 25 Jun 2008 10:35:37 +0000
Received: from [192.18.43.25] (helo=sca-ea-mail-2.sun.com)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.69 (FreeBSD))
	(envelope-from <erik.nordmark@sun.com>)
	id 1KBSLY-0008Aq-3r
	for v6ops@ops.ietf.org; Wed, 25 Jun 2008 10:35:32 +0000
Received: from jurassic.eng.sun.com ([129.146.228.50])
	by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PAZRN8000183;
	Wed, 25 Jun 2008 10:35:27 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PAZFbn832915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jun 2008 03:35:17 -0700 (PDT)
Message-ID: <48621F62.2060403@sun.com>
Date: Wed, 25 Jun 2008 03:35:14 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: David Miles <davidm@thetiger.com>
CC: v6ops@ops.ietf.org
Subject: Re: Neighbor Discovery and on-link determination
References: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz>
In-Reply-To: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

David Miles wrote:
> I have seen an unusual scenario which I was wanting to run past people 
> to comment on:
> 
> I have routerA and routerB connected to each other via Ethernet.
> 
> RouterA has the following addresses on the interface to RouterB:
> 2000:100::2/64
> 3000:100::2/64
> With a default route to 2000:100::1
> 
> RouterB has the following addresses on the interface to RouterA:
> 2000:100::1/64
> With a route for 3000:100::/64 to 2000:100::2

So the routers are intentionally configured to have different on-link 
prefixes?

> Per RFC4861, RouterA is sending ND as follows (assume it wants to src 
> traffic from 3000:100::2 to a off-link address):
>    3000:1::2 -> FF02::1:FF00:1
>    Type: Neighbor Solicitation (135)
>    Code: No Code (0)
>       Tgt Addr: 2000:100::1
>       Option  : Src Link Layer Addr 00:00:00:00:00:01
> 
> As 7.2.2 says "if the source address of the packet prompting the 
> solicitation is the same as one of the addresses assigned to the 
> outgoing interface, that address SHOULD be placed in the IP Source 
> Address of the outgoing solicitation."
> 
> When RouterB will receive the ND as it is sent to the solicited-node MC 
> address and will check the target address is valid (matches an addresss 
> assigned to the receiving interface).
> RouterB should then create a Neighbour Cache entry and set its state to 
> STALE using the link-layer address in the ND. It should then send a 
> solicited neighbor advertisement.
> 
> This means that the RouterB will have a single address 3000:1::2 in its 
> Neighbour Cache, but the route will direct traffic to 2000:200::2. 
> Obviously the Neighbour Cache would now contain an entry for an address 
> that does not (appear) to be on-link from a route-table perspective.

Correct. The same thing is true for a host receiving a redirect where 
the target is on-link.

> How should Neighbour Cache and route table interact on a routerB? I had 
> always assumed route table replaces Prefix List on a router, but that 
> would mean Neighbour Cache would always be consulted with the next-hop 
> of the static route (following the sending algorithm in RFC 4861).

Since the neighbor cache is per-interface the routing table needs to be 
consulted first, and only what that results in knowing the interface on 
which to send the packet does the neighbor cache get consulted.

But I don't think there is anything in the RFC that explicitly spells 
that out.

> This seems to directly relate to the definition of on-link as being:
> - an address covered by on of the link's prefixes, or
> - an address in the target of a rediect, or
> - an address in the target of a neigbour advertisement, or
> - an address in the source of a neighbour discovery message
> 
> Should a router really consider an address on-link just because it 
> received a ND - I can see many potential security concerns if that is 
> the case.

Given that the neighbor cache is per interface, can you give me an 
example of where this causes a security concern?

    Erik



From owner-v6ops@ops.ietf.org  Wed Jun 25 03:42:33 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EB4E83A6A66
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 25 Jun 2008 03:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.495
X-Spam-Level: 
X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1]
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 EyyaG3DCXhhF
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 25 Jun 2008 03:42:32 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 2BD4B3A6A4A
	for <v6ops-archive@lists.ietf.org>; Wed, 25 Jun 2008 03:42:32 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KBSOX-0008S5-4k
	for v6ops-data@psg.com; Wed, 25 Jun 2008 10:38:33 +0000
Received: from [192.18.43.22] (helo=sca-ea-mail-4.sun.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <erik.nordmark@sun.com>)
	id 1KBSOP-0008RR-Q3
	for v6ops@ops.ietf.org; Wed, 25 Jun 2008 10:38:31 +0000
Received: from jurassic.eng.sun.com ([129.146.104.31])
	by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PAcP6k017808;
	Wed, 25 Jun 2008 10:38:25 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PAcIVR832947
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jun 2008 03:38:20 -0700 (PDT)
Message-ID: <4862201A.4040409@sun.com>
Date: Wed, 25 Jun 2008 03:38:18 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: David Miles <davidm@thetiger.com>
CC: Thomas Narten <narten@us.ibm.com>, IETF V6OPS WG <v6ops@ops.ietf.org>
Subject: Re: Neighbor Discovery and on-link determination
References: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz> <200806241536.m5OFanr6005744@cichlid.raleigh.ibm.com> <C93F5BD2-225F-493A-B8B9-E0BC28C94037@thetiger.com>
In-Reply-To: <C93F5BD2-225F-493A-B8B9-E0BC28C94037@thetiger.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

David Miles wrote:

> I'd also suggest that in the Message Validation section we include the 
> checks you mention (is the source of the ND or target of the NA an 
> on-link prefix per Prefix List)

If you do that, how would communication work in your example?
The NS would be dropped since its source isn't covered by an on-link 
prefix on the receiver, right?

    Erik





From owner-v6ops@ops.ietf.org  Wed Jun 25 04:20:09 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9A1A228C140
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 25 Jun 2008 04:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level: 
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=0.300,
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
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 vZW2THKK11B9
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 25 Jun 2008 04:20:03 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id A8B3A28C149
	for <v6ops-archive@lists.ietf.org>; Wed, 25 Jun 2008 04:20:03 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KBT0y-000CZM-Ab
	for v6ops-data@psg.com; Wed, 25 Jun 2008 11:18:16 +0000
Received: from [74.53.155.170] (helo=wibble.focb.co.nz)
	by psg.com with smtp (Exim 4.69 (FreeBSD))
	(envelope-from <davidm@thetiger.com>)
	id 1KBT0u-000CYi-GB
	for v6ops@ops.ietf.org; Wed, 25 Jun 2008 11:18:14 +0000
Received: (qmail 3062 invoked by uid 509); 25 Jun 2008 11:18:10 -0000
Received: from 211.28.128.246 by wibble.focb.co.nz (envelope-from <davidm@thetiger.com>, uid 89) with qmail-scanner-2.01 
 (clamdscan: 0.93.1/7554. spamassassin: 3.2.4.  
 Clear:RC:1(211.28.128.246):. 
 Processed in 0.045009 secs); 25 Jun 2008 11:18:10 -0000
Received: from c211-28-128-246.smelb2.vic.optusnet.com.au (HELO [10.0.1.100]) (211.28.128.246)
	by 0 with SMTP; Wed, 25 Jun 2008 06:18:09 -0500
Cc: Thomas Narten <narten@us.ibm.com>,
 IETF V6OPS WG <v6ops@ops.ietf.org>
Message-Id: <AB66914B-7B0B-4505-A796-DB2B9E605F05@thetiger.com>
From: David Miles <davidm@thetiger.com>
To: Erik Nordmark <erik.nordmark@sun.com>
In-Reply-To: <4862201A.4040409@sun.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Neighbor Discovery and on-link determination
Date: Wed, 25 Jun 2008 21:18:05 +1000
References: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz> <200806241536.m5OFanr6005744@cichlid.raleigh.ibm.com> <C93F5BD2-225F-493A-B8B9-E0BC28C94037@thetiger.com> <4862201A.4040409@sun.com>
X-Mailer: Apple Mail (2.924)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


Hi Erik,

I'll put both answers into one email:


If routerA sent a ND to routerB and the source address of the ND if  
off-link, populating the Neighbour Cache will not achieve any real  
functionality. Yes, I'd propose it is ignored by the router. Possibly  
we could trigger a unsolicited Neighbour Advertisement from RouterB?
I cannot see any impact on redirect or proxy service functionality and  
I really see this as a misconfiguration.

With respect to your other email and my security concerns:  if  the  
receipt of a ND or NA on any interface, irrespective of prefix list,  
were able to both populate the Neighbour Cache and update/affect the  
forwarding behaviour then I would be worried. Seeing you have both  
clarified this was not the intent I do not have an issue, but it does  
seem of little benefit to populate a Neighbour Cache entry if it is  
never consulted.

I know the scenario is contrived however it was brought to my  
attention from another source, so the clarifications are appreciated.

Best Regards,

-David


On 25/06/2008, at 8:38 PM, Erik Nordmark wrote:

> David Miles wrote:
>
>> I'd also suggest that in the Message Validation section we include  
>> the checks you mention (is the source of the ND or target of the NA  
>> an on-link prefix per Prefix List)
>
> If you do that, how would communication work in your example?
> The NS would be dropped since its source isn't covered by an on-link  
> prefix on the receiver, right?
>
>   Erik
>
>




From c.girard@bm-stjeandevedas.fr  Wed Jun 25 04:58:56 2008
Return-Path: <c.girard@bm-stjeandevedas.fr>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6A3763A6A7D;
	Wed, 25 Jun 2008 04:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -83.246
X-Spam-Level: 
X-Spam-Status: No, score=-83.246 tagged_above=-999 required=5
	tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426,
	RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	USER_IN_WHITELIST=-100]
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 CTYfGx7-DZR0; Wed, 25 Jun 2008 04:58:55 -0700 (PDT)
Received: from dynamic-66-243-245-4.ellensburg.fairpoint.net (dynamic-66-243-245-4.ellensburg.fairpoint.net [66.243.245.4])
	by core3.amsl.com (Postfix) with SMTP id 474853A6A77;
	Wed, 25 Jun 2008 04:58:52 -0700 (PDT)
X-Originating-IP: 47.199.172.145 by smtp.66.243.245.4;  Wed, 25 Jun 2008 07:58:46 -0500
Message-ID: <pukmknkIMFTKKsmime-archive@megatron.ietf.org>
From: "Oscar Morris" <smime-archive@megatron.ietf.org>
Reply-To: "Oscar Morris" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Impressive Glashutte timepieces
Date: Wed, 25 Jun 2008 07:58:46 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable.
http://www.geocities.com/richardsfinola

As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today!
http://www.geocities.com/richardsfinola





From owner-v6ops@ops.ietf.org  Wed Jun 25 06:30:53 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4323C3A6862
	for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 25 Jun 2008 06:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.495
X-Spam-Level: 
X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
	RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1]
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 0wrSNa-HIbr0
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Wed, 25 Jun 2008 06:30:49 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 0D3003A69EC
	for <v6ops-archive@lists.ietf.org>; Wed, 25 Jun 2008 06:30:49 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KBV0R-0000sl-IC
	for v6ops-data@psg.com; Wed, 25 Jun 2008 13:25:51 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <erik.nordmark@sun.com>)
	id 1KBV0K-0000rd-10
	for v6ops@ops.ietf.org; Wed, 25 Jun 2008 13:25:45 +0000
Received: from jurassic.eng.sun.com ([129.146.228.50])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5PDPhmt021007;
	Wed, 25 Jun 2008 13:25:43 GMT
Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248])
	by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PDPdaT835949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jun 2008 06:25:41 -0700 (PDT)
Message-ID: <48624752.7020809@sun.com>
Date: Wed, 25 Jun 2008 06:25:38 -0700
From: Erik Nordmark <erik.nordmark@sun.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070723)
MIME-Version: 1.0
To: David Miles <davidm@thetiger.com>
CC: Thomas Narten <narten@us.ibm.com>, IETF V6OPS WG <v6ops@ops.ietf.org>
Subject: Re: Neighbor Discovery and on-link determination
References: <alpine.LRH.1.10.0806222254000.7835@wibble.focb.co.nz> <200806241536.m5OFanr6005744@cichlid.raleigh.ibm.com> <C93F5BD2-225F-493A-B8B9-E0BC28C94037@thetiger.com> <4862201A.4040409@sun.com> <AB66914B-7B0B-4505-A796-DB2B9E605F05@thetiger.com>
In-Reply-To: <AB66914B-7B0B-4505-A796-DB2B9E605F05@thetiger.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

David Miles wrote:
> 
> Hi Erik,
> 
> I'll put both answers into one email:
> 
> 
> If routerA sent a ND to routerB and the source address of the ND if 
> off-link, populating the Neighbour Cache will not achieve any real 
> functionality. Yes, I'd propose it is ignored by the router. Possibly we 
> could trigger a unsolicited Neighbour Advertisement from RouterB?
> I cannot see any impact on redirect or proxy service functionality and I 
> really see this as a misconfiguration.

The message validation rules that you referred to are cases when the 
packet would be ignored (and that would be problematic for sure.)

It makes sense to look carefully at the effect of "do not create a 
neighbor cache entry for the sender if sender is not in one of the 
on-link prefixes".

> With respect to your other email and my security concerns:  if  the 
> receipt of a ND or NA on any interface, irrespective of prefix list, 
> were able to both populate the Neighbour Cache and update/affect the 
> forwarding behaviour then I would be worried. Seeing you have both 
> clarified this was not the intent I do not have an issue, but it does 
> seem of little benefit to populate a Neighbour Cache entry if it is 
> never consulted.
> 
> I know the scenario is contrived however it was brought to my attention 
> from another source, so the clarifications are appreciated.

OK

    Erik



From cabarca@iconstruccion.cl  Wed Jun 25 16:49:19 2008
Return-Path: <cabarca@iconstruccion.cl>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 847B428C0E4;
	Wed, 25 Jun 2008 16:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -48.071
X-Spam-Level: 
X-Spam-Status: No, score=-48.071 tagged_above=-999 required=5
	tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357,
	GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426,
	RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
	RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666,
	SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666,
	SARE_SPEC_ROLEX_REP=1.666, USER_IN_WHITELIST=-100]
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 edaA6U3jI7zS; Wed, 25 Jun 2008 16:49:12 -0700 (PDT)
Received: from cable201-233-63-49.epm.net.co (cable201-233-63-49.epm.net.co [201.233.63.49])
	by core3.amsl.com (Postfix) with SMTP id 79AAB3A68CF;
	Wed, 25 Jun 2008 16:48:53 -0700 (PDT)
X-Originating-IP: 180.52.94.102 by smtp.201.233.63.49;  Wed, 25 Jun 2008 19:48:46 -0500
Message-ID: <ikiofJEKEQsmime-archive@megatron.ietf.org>
From: "Alissa Yeager" <smime-archive@megatron.ietf.org>
Reply-To: "Alissa Yeager" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: Replica watches make great gifts
Date: Wed, 25 Jun 2008 19:48:46 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers.
http://walipifavyb30.blogspot.com/

Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal!
http://walipifavyb30.blogspot.com/





From cabana@mjcoady.com  Thu Jun 26 03:25:30 2008
Return-Path: <cabana@mjcoady.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 99D2B3A691E;
	Thu, 26 Jun 2008 03:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -84.114
X-Spam-Level: 
X-Spam-Status: No, score=-84.114 tagged_above=-999 required=5
	tests=[BAYES_60=1, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144,
	RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
	RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	USER_IN_WHITELIST=-100]
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 0fbhP65pb1Hl; Thu, 26 Jun 2008 03:25:28 -0700 (PDT)
Received: from 46.pool85-54-49.dynamic.orange.es (46.pool85-54-49.dynamic.orange.es [85.54.49.46])
	by core3.amsl.com (Postfix) with SMTP id 472803A6910;
	Thu, 26 Jun 2008 03:25:20 -0700 (PDT)
X-Originating-IP: 77.108.176.141 by smtp.85.54.49.46;  Thu, 26 Jun 2008 06:25:25 -0500
Message-ID: <lbnijzpZKDGBKtsv-area@ietf.org>
From: "Margaret Hale" <tsv-area@ietf.org>
Reply-To: "Margaret Hale" <tsv-area@ietf.org>
To: tsv-area@ietf.org
Subject: Why get an original watch?
Date: Thu, 26 Jun 2008 06:25:25 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Diamond Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable.
http://rakozasuxut57.blogspot.com/

As you are probably aware of, Diamond Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Diamond Replicas today!
http://rakozasuxut57.blogspot.com/





From c92wo@hackberry.org  Thu Jun 26 07:51:04 2008
Return-Path: <c92wo@hackberry.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 909B73A6904;
	Thu, 26 Jun 2008 07:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -69.795
X-Spam-Level: 
X-Spam-Status: No, score=-69.795 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597,
	FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,
	FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295,
	HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129,
	HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RCVD_IN_PBL=0.905,
	RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666,
	SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062,
	SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931,
	USER_IN_WHITELIST=-100]
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 256VEelibZRs; Thu, 26 Jun 2008 07:50:59 -0700 (PDT)
Received: from 189-18-189-212.dsl.telesp.net.br (189-18-189-212.dsl.telesp.net.br [189.18.189.212])
	by core3.amsl.com (Postfix) with SMTP id ED99B3A67DF;
	Thu, 26 Jun 2008 07:50:46 -0700 (PDT)
X-Originating-IP: 142.206.176.224 by smtp.189.18.189.212;  Thu, 26 Jun 2008 10:50:39 -0500
Message-ID: <umebxTJPVRYWsmime-archive@megatron.ietf.org>
From: "Georgia Irving" <smime-archive@megatron.ietf.org>
Reply-To: "Georgia Irving" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: You can save 80%
Date: Thu, 26 Jun 2008 10:50:39 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200.
http://bukimotedug86.blogspot.com/

For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas.
http://bukimotedug86.blogspot.com/





From c.snitkin@schmiedag.de  Thu Jun 26 08:13:51 2008
Return-Path: <c.snitkin@schmiedag.de>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BCF093A67D0;
	Thu, 26 Jun 2008 08:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -54.992
X-Spam-Level: 
X-Spam-Status: No, score=-54.992 tagged_above=-999 required=5
	tests=[BAYES_95=3, FB_QUALITY_REPLICA=10.357,
	FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5,
	HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5,
	RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905,
	RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666,
	SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666,
	SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 m+ZS1wqMEHM8; Thu, 26 Jun 2008 08:13:51 -0700 (PDT)
Received: from 201-212-52-188.cab.prima.net.ar (201-212-52-188.cab.prima.net.ar [201.212.52.188])
	by core3.amsl.com (Postfix) with SMTP id 331063A6816;
	Thu, 26 Jun 2008 08:13:45 -0700 (PDT)
X-Originating-IP: 171.95.184.104 by smtp.201.212.52.188;  Thu, 26 Jun 2008 11:13:38 -0500
Message-ID: <vhybeRMKNPRsmime-archive@megatron.ietf.org>
From: "Marguerite Sizemore" <smime-archive@megatron.ietf.org>
Reply-To: "Marguerite Sizemore" <smime-archive@megatron.ietf.org>
To: smime-archive@megatron.ietf.org
Subject: You and a Rolex watch
Date: Thu, 26 Jun 2008 11:13:38 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit
X-Antivirus: avast! (VPS 080626-1, 26/06/2008), Outbound message
X-Antivirus-Status: Clean


Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Diamond Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers.
http://morufegyzag38.blogspot.com/

Diamond Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal!
http://morufegyzag38.blogspot.com/





From c.lacroix@cbs-securite.com  Thu Jun 26 10:05:21 2008
Return-Path: <c.lacroix@cbs-securite.com>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E8D8E28C130;
	Thu, 26 Jun 2008 10:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -53.951
X-Spam-Level: 
X-Spam-Status: No, score=-53.951 tagged_above=-999 required=5
	tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
	FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994,
	FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295,
	HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129,
	HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96,
	RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_RECV_SPAM_DOMN02=1.666, SARE_SPEC_REPLICA_OBFU=1.812,
	SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666,
	TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100]
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 KK12ivB4YwPG; Thu, 26 Jun 2008 10:05:16 -0700 (PDT)
Received: from 201-95-77-190.dsl.telesp.net.br (201-95-77-190.dsl.telesp.net.br [201.95.77.190])
	by core3.amsl.com (Postfix) with SMTP id 0A6FA28C106;
	Thu, 26 Jun 2008 10:04:55 -0700 (PDT)
X-Originating-IP: 203.232.232.12 by smtp.201.95.77.190;  Thu, 26 Jun 2008 13:04:54 -0500
Message-ID: <gbuwllwFQQVOQuser@ietf.org>
From: "Wilfredo Gabriel" <user@ietf.org>
Reply-To: "Wilfredo Gabriel" <user@ietf.org>
To: user@ietf.org
Subject: New replica watches delivered fast
Date: Thu, 26 Jun 2008 13:04:54 -0500
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit


A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Diamond Replicas, the web's most comprehensive collection of brand name replica watches. In Diamond Replicas, any Tag Heuer is available for just over $200.
http://muwazywygad66.blogspot.com/

For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Diamond Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Diamond Replicas.
http://muwazywygad66.blogspot.com/





From owner-v6ops@ops.ietf.org  Mon Jun 30 10:21:30 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1E3013A6A10
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 30 Jun 2008 10:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level: 
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5
	tests=[AWL=-1.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4,
	RDNS_NONE=0.1]
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 aitsy3YmntvA
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 30 Jun 2008 10:21:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id F39E43A68FD
	for <v6ops-archive@lists.ietf.org>; Mon, 30 Jun 2008 10:21:28 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDMxE-0009Fv-SE
	for v6ops-data@psg.com; Mon, 30 Jun 2008 17:14:16 +0000
Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com)
	by psg.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.69 (FreeBSD))
	(envelope-from <wbeebee@cisco.com>)
	id 1KDMx9-0009El-E0
	for v6ops@ops.ietf.org; Mon, 30 Jun 2008 17:14:14 +0000
X-IronPort-AV: E=Sophos;i="4.27,728,1204520400"; 
   d="scan'208,217";a="12713734"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
  by rtp-iport-1.cisco.com with ESMTP; 30 Jun 2008 13:14:10 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5UHEA5W000509
	for <v6ops@ops.ietf.org>; Mon, 30 Jun 2008 13:14:10 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12])
	by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5UHEA69005073
	for <v6ops@ops.ietf.org>; Mon, 30 Jun 2008 17:14:10 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 30 Jun 2008 13:14:10 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8DAD4.B596A2F4"
Subject: new draft on IPv6 CPE router available for review
Date: Mon, 30 Jun 2008 13:14:22 -0400
Message-ID: <BB56240F3A190F469C52A57138047A03A2CC1D@xmb-rtp-211.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: new draft on IPv6 CPE router available for review
Thread-Index: AcjazbZEhWq/8Xu9TdqYgT/vjauSsQABugCg
From: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
To: <v6ops@ops.ietf.org>
Cc: "Hemant Singh (shemant)" <shemant@cisco.com>
X-OriginalArrivalTime: 30 Jun 2008 17:14:10.0257 (UTC) FILETIME=[B6115410:01C8DAD4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3142; t=1214846050; x=1215710050;
	c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=wbeebee@cisco.com;
	z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20<wbeebee@cisco.co
	m>
	|Subject:=20new=20draft=20on=20IPv6=20CPE=20router=20availa
	ble=20for=20review
	|Sender:=20
	|To:=20<v6ops@ops.ietf.org>;
	bh=qVOUwsXvnkIjCCHUujNWByy21d2JFfLs3HBuPnC/xGw=;
	b=hPeHDrkSORGGs8KFXRbefoaKco0BnmuPkuqm7aXrrnuZSKZuBzDRs1QZOv
	//0QSualX0+BOGl28wKLImFwRsclcJaKRfBcmlds51jPvA/AKPyvhyLYL6Dn
	21Qe68d6FS;
Authentication-Results: rtp-dkim-1; header.From=wbeebee@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8DAD4.B596A2F4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

v6ops folks,
=20
Please review this draft.
=20
http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.txt
=20
The Abstract of the draft is snipped below.
=20
Abstract

   This document recommends IPv6 behavior for Customer Premises
   Equipment (CPE) routers in Internet-enabled homes and small offices.

=20
Thanks.
=20
Hemant & Wes.

------_=_NextPart_001_01C8DAD4.B596A2F4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D390284515-30062008><FONT face=3DArial size=3D2><SPAN=20
class=3D536422116-30062008>v6ops folks,</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D390284515-30062008><FONT face=3DArial size=3D2><SPAN=20
class=3D536422116-30062008></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D390284515-30062008><FONT face=3DArial size=3D2><SPAN=20
class=3D536422116-30062008>Please review this =
draft.</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D390284515-30062008><FONT face=3DArial size=3D2><SPAN=20
class=3D536422116-30062008></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D390284515-30062008><FONT face=3DArial size=3D2><A=20
title=3Dhttp://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router=
-00.txt=20
href=3D"http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router=
-00.txt">http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-route=
r-00.txt</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D390284515-30062008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D390284515-30062008><SPAN =
class=3D536422116-30062008><FONT=20
face=3DArial size=3D2>The Abstract&nbsp;of the draft is&nbsp;snipped=20
below.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D390284515-30062008><SPAN =
class=3D536422116-30062008><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D390284515-30062008><SPAN=20
class=3D536422116-30062008>Abstract<BR><BR>&nbsp;&nbsp; This document =
recommends=20
IPv6 behavior for Customer Premises<BR>&nbsp;&nbsp; Equipment (CPE) =
routers in=20
Internet-enabled homes and small offices.<BR></SPAN></SPAN></DIV>
<DIV><SPAN class=3D390284515-30062008><SPAN =
class=3D536422116-30062008><FONT=20
face=3DArial size=3D2></FONT>&nbsp;</DIV></SPAN></SPAN>
<DIV><SPAN class=3D390284515-30062008><SPAN =
class=3D536422116-30062008><FONT=20
face=3DArial size=3D2>Thanks.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=3D390284515-30062008><SPAN =
class=3D536422116-30062008><FONT=20
face=3DArial size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D390284515-30062008><SPAN =
class=3D536422116-30062008><FONT=20
face=3DArial size=3D2>Hemant &amp; =
Wes.</FONT></SPAN></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C8DAD4.B596A2F4--



From owner-v6ops@ops.ietf.org  Mon Jun 30 11:51:00 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id ACFB23A6896
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 30 Jun 2008 11:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.721
X-Spam-Level: 
X-Spam-Status: No, score=-4.721 tagged_above=-999 required=5
	tests=[AWL=-0.826, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4,
	RDNS_NONE=0.1]
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 8OrKyb-W29K8
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 30 Jun 2008 11:50:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 78B9E3A679C
	for <v6ops-archive@lists.ietf.org>; Mon, 30 Jun 2008 11:50:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDOP6-000PVa-EQ
	for v6ops-data@psg.com; Mon, 30 Jun 2008 18:47:08 +0000
Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com)
	by psg.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.69 (FreeBSD))
	(envelope-from <wbeebee@cisco.com>)
	id 1KDOOs-000PTR-Hb
	for v6ops@ops.ietf.org; Mon, 30 Jun 2008 18:47:05 +0000
X-IronPort-AV: E=Sophos;i="4.27,728,1204520400"; 
   d="scan'208";a="12734276"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
  by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2008 14:46:53 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5UIkrg1031374;
	Mon, 30 Jun 2008 14:46:53 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12])
	by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5UIkrJ4024201;
	Mon, 30 Jun 2008 18:46:53 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Mon, 30 Jun 2008 14:46:53 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: new draft on IPv6 CPE router available for review
Date: Mon, 30 Jun 2008 14:47:06 -0400
Message-ID: <BB56240F3A190F469C52A57138047A03A2CCB4@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <alpine.DEB.1.10.0806302017000.31819@uplift.swm.pp.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: new draft on IPv6 CPE router available for review
Thread-Index: Acja3nUuXrn1Mn4YRridhQ7AiKGeMAAAufZw
From: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
To: "Mikael Abrahamsson" <swmike@swm.pp.se>
Cc: "Hemant Singh (shemant)" <shemant@cisco.com>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 30 Jun 2008 18:46:53.0551 (UTC) FILETIME=[AA0C9FF0:01C8DAE1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1963; t=1214851613; x=1215715613;
	c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=wbeebee@cisco.com;
	z=From:=20=22Wes=20Beebee=20(wbeebee)=22=20<wbeebee@cisco.co
	m>
	|Subject:=20RE=3A=20new=20draft=20on=20IPv6=20CPE=20router=
	20available=20for=20review
	|Sender:=20
	|To:=20=22Mikael=20Abrahamsson=22=20<swmike@swm.pp.se>;
	bh=AgUX8sRDnmVc3MU1xNCHThyYR5wo5i9eKD3k+0lQP5g=;
	b=PZCpYCcQ1vg+J0c7DfCeoQ6szlz00IR4mnMC3mo8C/wq2U9Zr/KlNahPRN
	mSps149KTQ03RbmjWtolkTTfDoTeQeWsxwBovVpWdiVKYdBaYFQlLa8NlD/y
	LsDoxEDgwX;
Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Mikael -=20

Thanks for this review.  Your comment makes a lot of sense.=20

We would be happy to incorporate your suggestion into our draft.

- Wes and Hemant

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20
Sent: Monday, June 30, 2008 2:24 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant)
Subject: Re: new draft on IPv6 CPE router available for review

On Mon, 30 Jun 2008, Wes Beebee (wbeebee) wrote:

> v6ops folks,
>
> Please review this draft.
>
> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-00.t
> xt
>
> The Abstract of the draft is snipped below.
>
> Abstract
>
>   This document recommends IPv6 behavior for Customer Premises
>   Equipment (CPE) routers in Internet-enabled homes and small offices.
>
>
> Thanks.
>
> Hemant & Wes.

Hello.

In section 5.3 I would definitely like a CPE to work without having a
WAN address (link local only). The rationale behind this is that we
would like ISP routers have IPs in a core IP-range (which will be
protected from DDOS by ratelimiters or filters) and have customers in
their own IP space. The handoff between distribution and CPE should be
done via something that is not reachable from the internet, ie the CPE
should never source packets from its WAN IP, instead it should source
packets destined to the internet from a loopback IP which it should
allocate to itself from DHCPv6-PD (it could also be a LAN interface IP).
So behavior would be "get link-local working, do DHCPv6-PD, allocate IP
to itself from PD range, then use THAT to provision itself further and
to communicate with everything".

>From what I read in 5.3, this behaviour would be in violation of the
draft you've written, so I would like your input on how my thoughts
above could be incorporated into your draft (which I think is an
excellent initiative).

Regards,

--=20
Mikael Abrahamsson    email: swmike@swm.pp.se



From owner-v6ops@ops.ietf.org  Mon Jun 30 18:28:54 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 39A713A6800
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 30 Jun 2008 18:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 g59bK4x-6LlH
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 30 Jun 2008 18:28:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 41B033A69B4
	for <v6ops-archive@lists.ietf.org>; Mon, 30 Jun 2008 18:28:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDUYE-00065W-Vd
	for v6ops-data@psg.com; Tue, 01 Jul 2008 01:20:58 +0000
Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <miyakawa@nttv6.jp>)
	id 1KDUY1-00063S-Ob
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 01:20:56 +0000
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26])
	by gura.nttv6.jp (NTTv6MTA) with ESMTP id C2BD5BDC08;
	Tue,  1 Jul 2008 10:20:44 +0900 (JST)
Received: from localhost (localhost.nttv6.jp [IPv6:::1])
	by z.nttv6.jp (NTTv6MTA) with ESMTP id 8CEDD6E358;
	Tue,  1 Jul 2008 10:20:44 +0900 (JST)
Date: Tue, 01 Jul 2008 10:20:44 +0900 (JST)
Message-Id: <20080701.102044.59751592.miyakawa@nttv6.jp>
To: wbeebee@cisco.com, swmike@swm.pp.se, shemant@cisco.com,
 v6ops@ops.ietf.org
Cc: miyakawa@nttv6.jp, yasuhiro@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
From: Shin Miyakawa <miyakawa@nttv6.jp>
In-Reply-To: <BB56240F3A190F469C52A57138047A03A2CCB4@xmb-rtp-211.amer.cisco.com>
References: <alpine.DEB.1.10.0806302017000.31819@uplift.swm.pp.se>
	<BB56240F3A190F469C52A57138047A03A2CCB4@xmb-rtp-211.amer.cisco.com>
Organizaton: NTT Communications
X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hello,

I have a comment on the transfered message by Wes,

> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
>
>
> In section 5.3 I would definitely like a CPE to work without having a
> WAN address (link local only). 

Actually, this does not work if a CPE use the strong host model implementation
describing in RFC1122 or STD3 : Requirements for Internet Hosts - Communication Layers.

> The rationale behind this is that we would like ISP routers have IPs 
> in a core IP-range (which will be protected from DDOS by ratelimiters or filters) 
> and have customers in their own IP space. 
> The handoff between distribution and CPE should be
> done via something that is not reachable from the internet, ie the CPE
> should never source packets from its WAN IP, instead it should source
> packets destined to the internet from a loopback IP which it should
> allocate to itself from DHCPv6-PD (it could also be a LAN interface IP).
> So behavior would be "get link-local working, do DHCPv6-PD, allocate IP
> to itself from PD range, then use THAT to provision itself further and
> to communicate with everything".

Originally, when we wrote RFC4241 (A Model of IPv6/IPv4 Dual Stack Internet 
Access Service) to start our IPv6/v4 dual stack native ADSL service, 
we also thought about same thing. So we can understand Mikael's will too.

But now Microsoft Vista and Windows 2008 IPv6 implementation are based on 
the strong host model as default, (please see 
http://technet.microsoft.com/en-us/library/bb878108.aspx
and
http://technet.microsoft.com/en-us/magazine/cc137807.aspx ).

Especially, if we think that the uplink is a "softwire" or the CPE is a brige,
Vista is one of the most likely to be used operating systems 
to terminate the IPv6 uplink by itself, so 
from practical point of view, we strongly recommend to assign a global IPv6 address.

We've just submitted a very short draft regarding this issue

http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt

and hope this could be merged to the section 5.3 of Wes's draft with its reasons.

Best regards,

Shin Miyakawa, Ph.D
Director, Core Network Technology Team, Network Systems and Technologies, 
Innovative IP Architecture Center /
Corporate Planning Department (concurrent position)
NTT Communications Corporation
Tokyo Opera City Tower 21st Floor
3-20-2 Nishi-Shinjuku, Shinjuku-Ku, Tokyo, Japan 163-1421
E-mail:miyakawa@nttv6.jp / shin.miyakawa@ntt.com / miyakawa@wide.ad.jp
TEL:+81-3-6800-3262 / FAX:+81-3-5365-2990
Visiting Researcher, SFC Lab. KEIO University
WIDE Project



From owner-v6ops@ops.ietf.org  Mon Jun 30 22:51:56 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B0F663A685F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 30 Jun 2008 22:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.348
X-Spam-Level: 
X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5
	tests=[AWL=0.252, BAYES_00=-2.599, NO_RELAYS=-0.001,
	USER_IN_WHITELIST=-100]
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 4X-XqbjNqlLT
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 30 Jun 2008 22:51:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id C77323A67D7
	for <v6ops-archive@lists.ietf.org>; Mon, 30 Jun 2008 22:51:55 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDYgC-000Jo2-AD
	for v6ops-data@psg.com; Tue, 01 Jul 2008 05:45:28 +0000
Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <root@core3.amsl.com>)
	id 1KDYfy-000Jm0-AR
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 05:45:16 +0000
Received: by core3.amsl.com (Postfix, from userid 0)
	id D8E3E3A67D7; Mon, 30 Jun 2008 22:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
Subject: I-D Action:draft-ietf-v6ops-ra-guard-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080701054501.D8E3E3A67D7@core3.amsl.com>
Date: Mon, 30 Jun 2008 22:45:01 -0700 (PDT)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.


	Title           : IPv6 RA-Guard
	Author(s)       : G. Van de Velde, et al.
	Filename        : draft-ietf-v6ops-ra-guard-00.txt
	Pages           : 9
	Date            : 2008-06-30

When using IPv6 within a single L2 network segment it is neccesary to
ensure that all routers advertising their services within it are
valid.  In cases where it is not convinient or possible to use SeND
[RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent
by accident due to misconfiguraton or ill intended.  Simple solutions
for protecting against rogue RAs are beneficial in complementing SeND
in securing the L2 domain for ceratin types of devices or in certain
transitional situations.
This document proposes a solution to reduce the threat of rogue RAs
by enabling layer 2 devices to forward only RAs received over
designated ports.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-ra-guard-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-06-30224333.I-D@ietf.org>

--NextPart--



From owner-v6ops@ops.ietf.org  Mon Jun 30 23:57:25 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A1F5B3A687C
	for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 30 Jun 2008 23:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Hz-DyMd5on6A
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Mon, 30 Jun 2008 23:57:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id BF2E13A67D6
	for <v6ops-archive@lists.ietf.org>; Mon, 30 Jun 2008 23:57:24 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDZkM-0004iw-T6
	for v6ops-data@psg.com; Tue, 01 Jul 2008 06:53:50 +0000
Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <swmike@swm.pp.se>)
	id 1KDZkI-0004iD-QD
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 06:53:48 +0000
Received: by uplift.swm.pp.se (Postfix, from userid 501)
	id B6462ADADF; Tue,  1 Jul 2008 08:53:45 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by uplift.swm.pp.se (Postfix) with ESMTP id 7A9E6ADAD9;
	Tue,  1 Jul 2008 08:53:45 +0200 (CEST)
Date: Tue, 1 Jul 2008 08:53:45 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Shin Miyakawa <miyakawa@nttv6.jp>
cc: wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, 
    yasuhiro@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
In-Reply-To: <20080701.102044.59751592.miyakawa@nttv6.jp>
Message-ID: <alpine.DEB.1.10.0807010842020.21378@uplift.swm.pp.se>
References: <alpine.DEB.1.10.0806302017000.31819@uplift.swm.pp.se> <BB56240F3A190F469C52A57138047A03A2CCB4@xmb-rtp-211.amer.cisco.com> <20080701.102044.59751592.miyakawa@nttv6.jp>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Tue, 1 Jul 2008, Shin Miyakawa wrote:

> to terminate the IPv6 uplink by itself, so from practical point of view, 
> we strongly recommend to assign a global IPv6 address.

Well, my personal opinion is that this makes Vista unfit to be a IPv6 CPE. 
We cannot adjust IPv6 address policy just because of certain design 
decisions on behalf of Microsoft.

It is my belief that customers (at least in the market I am in) will need 
to have a small CPE that is not an end host, and this is what the draft 
should be aimed at. Advocating PPP is also a very bad idea as this cements 
the use of LAC/LNS and tunneling, which is a really bad idea for future 
multicast use, as well as being more expensive than necessary.

My idea of a good IPv6 service is one that is purely IPv6 over ethernet, 
optionally with 1-2 q tags or mac-in-mac in the ISP part of the network, 
but definitely not involving PPP or L2TP anywhere in the path.

At least, how can we make the draft comply so that what I would like to do 
doesn't violate any draft? I can understand if both options are in there, 
but making my proposal a draft violation seems like a bad idea, as we both 
seem to agree that it's the proper thing to do?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se



From owner-v6ops@ops.ietf.org  Tue Jul  1 00:49:01 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 095463A6A94
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue,  1 Jul 2008 00:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 iyh7xj-Pt6Wl
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue,  1 Jul 2008 00:49:00 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 307E33A6A82
	for <v6ops-archive@lists.ietf.org>; Tue,  1 Jul 2008 00:49:00 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDaZA-000D0D-Gw
	for v6ops-data@psg.com; Tue, 01 Jul 2008 07:46:20 +0000
Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <miyakawa@nttv6.jp>)
	id 1KDaZ6-000Czh-QM
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 07:46:18 +0000
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26])
	by gura.nttv6.jp (NTTv6MTA) with ESMTP id 62659BDC08;
	Tue,  1 Jul 2008 16:46:16 +0900 (JST)
Received: from localhost (localhost.nttv6.jp [IPv6:::1])
	by z.nttv6.jp (NTTv6MTA) with ESMTP id 3083B6E358;
	Tue,  1 Jul 2008 16:46:16 +0900 (JST)
Date: Tue, 01 Jul 2008 16:46:16 +0900 (JST)
Message-Id: <20080701.164616.226776039.miyakawa@nttv6.jp>
To: swmike@swm.pp.se
Cc: wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org,
 yasuhiro@nttv6.jp, miyakawa@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
From: Shin Miyakawa <miyakawa@nttv6.jp>
In-Reply-To: <alpine.DEB.1.10.0807010842020.21378@uplift.swm.pp.se>
References: <BB56240F3A190F469C52A57138047A03A2CCB4@xmb-rtp-211.amer.cisco.com>
	<20080701.102044.59751592.miyakawa@nttv6.jp>
	<alpine.DEB.1.10.0807010842020.21378@uplift.swm.pp.se>
Organizaton: NTT Communications
X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Mikael,

> > to terminate the IPv6 uplink by itself, so from practical point of view, 
> > we strongly recommend to assign a global IPv6 address.
> 
> Well, my personal opinion is that this makes Vista unfit to be a IPv6 CPE. 

fmmm.

> We cannot adjust IPv6 address policy just because of certain design 
> decisions on behalf of Microsoft.

I use that Vista is just as one example.
The Strong Host Model is defined in RFC1122 or STD3. That's a standard.

best wishes,

Shin Miyakawa



From owner-v6ops@ops.ietf.org  Tue Jul  1 00:53:14 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3A5293A6B2F
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue,  1 Jul 2008 00:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 UPJoGaIfY3l2
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue,  1 Jul 2008 00:53:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 52BB53A6AE6
	for <v6ops-archive@lists.ietf.org>; Tue,  1 Jul 2008 00:53:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDaec-000DjO-3a
	for v6ops-data@psg.com; Tue, 01 Jul 2008 07:51:58 +0000
Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <swmike@swm.pp.se>)
	id 1KDaeY-000Dih-4v
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 07:51:56 +0000
Received: by uplift.swm.pp.se (Postfix, from userid 501)
	id 44D8EADADE; Tue,  1 Jul 2008 09:51:53 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by uplift.swm.pp.se (Postfix) with ESMTP id 3794DADADD;
	Tue,  1 Jul 2008 09:51:53 +0200 (CEST)
Date: Tue, 1 Jul 2008 09:51:53 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Shin Miyakawa <miyakawa@nttv6.jp>
cc: wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, 
    yasuhiro@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
In-Reply-To: <20080701.164616.226776039.miyakawa@nttv6.jp>
Message-ID: <alpine.DEB.1.10.0807010948240.21378@uplift.swm.pp.se>
References: <BB56240F3A190F469C52A57138047A03A2CCB4@xmb-rtp-211.amer.cisco.com> <20080701.102044.59751592.miyakawa@nttv6.jp> <alpine.DEB.1.10.0807010842020.21378@uplift.swm.pp.se> <20080701.164616.226776039.miyakawa@nttv6.jp>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Tue, 1 Jul 2008, Shin Miyakawa wrote:

> I use that Vista is just as one example. The Strong Host Model is 
> defined in RFC1122 or STD3. That's a standard.

But if it's a router (which I think is what is needed for a IPv6 CPE) then 
it should be able to act as one, and use loopback interfaces to source 
traffic.

So if MS is serious about Vista being capable of acting a router/home 
gateway, then they should include capabilties needed for such a device. 
Sourcing traffic from loopback interfaces is important for a router.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se



From owner-v6ops@ops.ietf.org  Tue Jul  1 01:06:50 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CF6373A69FC
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue,  1 Jul 2008 01:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 DRcL+03ENXRs
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue,  1 Jul 2008 01:06:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id 1E1763A6A82
	for <v6ops-archive@lists.ietf.org>; Tue,  1 Jul 2008 01:06:48 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDapn-000FPo-Hh
	for v6ops-data@psg.com; Tue, 01 Jul 2008 08:03:31 +0000
Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <miyakawa@nttv6.jp>)
	id 1KDapj-000FPI-UE
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 08:03:29 +0000
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26])
	by gura.nttv6.jp (NTTv6MTA) with ESMTP id 80CCEBDC08;
	Tue,  1 Jul 2008 17:03:27 +0900 (JST)
Received: from localhost (localhost.nttv6.jp [IPv6:::1])
	by z.nttv6.jp (NTTv6MTA) with ESMTP id 4B9CA6E358;
	Tue,  1 Jul 2008 17:03:27 +0900 (JST)
Date: Tue, 01 Jul 2008 17:03:27 +0900 (JST)
Message-Id: <20080701.170327.104054108.miyakawa@nttv6.jp>
To: swmike@swm.pp.se
Cc: wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org,
 yasuhiro@nttv6.jp, miyakawa@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
From: Shin Miyakawa <miyakawa@nttv6.jp>
In-Reply-To: <alpine.DEB.1.10.0807010948240.21378@uplift.swm.pp.se>
References: <alpine.DEB.1.10.0807010842020.21378@uplift.swm.pp.se>
	<20080701.164616.226776039.miyakawa@nttv6.jp>
	<alpine.DEB.1.10.0807010948240.21378@uplift.swm.pp.se>
Organizaton: NTT Communications
X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Mikael,

Let us forget about how Microsoft is doing :-)

> > I use that Vista is just as one example. The Strong Host Model is 
> > defined in RFC1122 or STD3. That's a standard.
> 
> But if it's a router (which I think is what is needed for a IPv6 CPE) then 
> it should be able to act as one, and use loopback interfaces to source 
> traffic.

Even in this case, some software which is going to send a packet to the network
from CPE, according to RFC3484 "Default Address Selection for IPv6",
there is a certain reason why the WAN I/F's IP address should be used as
its source address like follows.

   ---------------- from RFC3484 ----------------
   It is RECOMMENDED that the candidate source addresses be the set of
   unicast addresses assigned to the interface that will be used to send
   to the destination.  (The "outgoing" interface.)  On routers, the
   candidate set MAY include unicast addresses assigned to any interface
   that forwards packets, subject to the restrictions described below.

      Discussion:  The Neighbor Discovery Redirect mechanism [14]
      requires that routers verify that the source address of a packet
      identifies a neighbor before generating a Redirect, so it is
      advantageous for hosts to choose source addresses assigned to the
      outgoing interface.  Implementations that wish to support the use
      of global source addresses assigned to a loopback interface should
      behave as if the loopback interface originates and forwards the
      packet.
   ---------------- from RFC3484 ----------------

Best wishes,

Shin Miyakawa



From owner-v6ops@ops.ietf.org  Tue Jul  1 01:18:33 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C0B653A6A94
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue,  1 Jul 2008 01:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ecXGOcs756z1
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue,  1 Jul 2008 01:18:33 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id E67493A682B
	for <v6ops-archive@lists.ietf.org>; Tue,  1 Jul 2008 01:18:32 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDb2g-000HSP-Ce
	for v6ops-data@psg.com; Tue, 01 Jul 2008 08:16:50 +0000
Received: from [2001:698:0:1:208:c7ff:fe91:b35a] (helo=uplift.swm.pp.se)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <swmike@swm.pp.se>)
	id 1KDb2c-000HRv-Mn
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 08:16:48 +0000
Received: by uplift.swm.pp.se (Postfix, from userid 501)
	id C99F4ADADF; Tue,  1 Jul 2008 10:16:45 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by uplift.swm.pp.se (Postfix) with ESMTP id BC61EADADE;
	Tue,  1 Jul 2008 10:16:45 +0200 (CEST)
Date: Tue, 1 Jul 2008 10:16:45 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Shin Miyakawa <miyakawa@nttv6.jp>
cc: wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org, 
    yasuhiro@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
In-Reply-To: <20080701.170327.104054108.miyakawa@nttv6.jp>
Message-ID: <alpine.DEB.1.10.0807011015180.21378@uplift.swm.pp.se>
References: <alpine.DEB.1.10.0807010842020.21378@uplift.swm.pp.se> <20080701.164616.226776039.miyakawa@nttv6.jp> <alpine.DEB.1.10.0807010948240.21378@uplift.swm.pp.se> <20080701.170327.104054108.miyakawa@nttv6.jp>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Tue, 1 Jul 2008, Shin Miyakawa wrote:

> Even in this case, some software which is going to send a packet to the network
> from CPE, according to RFC3484 "Default Address Selection for IPv6",
> there is a certain reason why the WAN I/F's IP address should be used as
> its source address like follows.
>   ---------------- from RFC3484 ----------------
>   It is RECOMMENDED that the candidate source addresses be the set of
>   unicast addresses assigned to the interface that will be used to send
>   to the destination.  (The "outgoing" interface.)  On routers, the
>   candidate set MAY include unicast addresses assigned to any interface
>   that forwards packets, subject to the restrictions described below.

What is the reason for this recommendation?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se



From owner-v6ops@ops.ietf.org  Tue Jul  1 01:28:06 2008
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BF0043A68C6
	for <ietfarch-v6ops-archive@core3.amsl.com>; Tue,  1 Jul 2008 01:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 mdKYL7vW5bNp
	for <ietfarch-v6ops-archive@core3.amsl.com>;
	Tue,  1 Jul 2008 01:28:03 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
	by core3.amsl.com (Postfix) with ESMTP id DA8283A682B
	for <v6ops-archive@lists.ietf.org>; Tue,  1 Jul 2008 01:28:02 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
	(envelope-from <owner-v6ops@ops.ietf.org>)
	id 1KDbBz-000Ip2-18
	for v6ops-data@psg.com; Tue, 01 Jul 2008 08:26:27 +0000
Received: from [2001:218:1f01:2::2] (helo=gura.nttv6.jp)
	by psg.com with esmtp (Exim 4.69 (FreeBSD))
	(envelope-from <miyakawa@nttv6.jp>)
	id 1KDbBv-000InI-BQ
	for v6ops@ops.ietf.org; Tue, 01 Jul 2008 08:26:25 +0000
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26])
	by gura.nttv6.jp (NTTv6MTA) with ESMTP id E72B0BDC08;
	Tue,  1 Jul 2008 17:26:22 +0900 (JST)
Received: from localhost (localhost.nttv6.jp [IPv6:::1])
	by z.nttv6.jp (NTTv6MTA) with ESMTP id BE3C06E358;
	Tue,  1 Jul 2008 17:26:22 +0900 (JST)
Date: Tue, 01 Jul 2008 17:26:22 +0900 (JST)
Message-Id: <20080701.172622.189700200.miyakawa@nttv6.jp>
To: swmike@swm.pp.se
Cc: wbeebee@cisco.com, shemant@cisco.com, v6ops@ops.ietf.org,
 yasuhiro@nttv6.jp, miyakawa@nttv6.jp
Subject: Re: new draft on IPv6 CPE router available for review
From: Shin Miyakawa <miyakawa@nttv6.jp>
In-Reply-To: <alpine.DEB.1.10.0807011015180.21378@uplift.swm.pp.se>
References: <alpine.DEB.1.10.0807010948240.21378@uplift.swm.pp.se>
	<20080701.170327.104054108.miyakawa@nttv6.jp>
	<alpine.DEB.1.10.0807011015180.21378@uplift.swm.pp.se>
Organizaton: NTT Communications
X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

From: Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: new draft on IPv6 CPE router available for review
Date: Tue, 1 Jul 2008 10:16:45 +0200 (CEST)

> On Tue, 1 Jul 2008, Shin Miyakawa wrote:
> 
> > Even in this case, some software which is going to send a packet to the network
> > from CPE, according to RFC3484 "Default Address Selection for IPv6",
> > there is a certain reason why the WAN I/F's IP address should be used as
> > its source address like follows.
> >   ---------------- from RFC3484 ----------------
> >   It is RECOMMENDED that the candidate source addresses be the set of
> >   unicast addresses assigned to the interface that will be used to send
> >   to the destination.  (The "outgoing" interface.)  On routers, the
> >   candidate set MAY include unicast addresses assigned to any interface
> >   that forwards packets, subject to the restrictions described below.
> 
> What is the reason for this recommendation?

Let's wait for the RFC author's answer :-)

Shin Miyakawa