Subject: [v6ops] Fwd: ID Tracker State Update Notice: <draft-ietf-v6ops-v6nd-problems-04.txt>

From: Joel jaeggli <[email-masked]>
Date: Sat, 03 Mar 2012 14:33:27 -0800

fyi It looks like this docuement is moving to publication.

-------- Original Message --------
Subject: ID Tracker State Update Notice:
<draft-ietf-v6ops-v6nd-problems-04.txt>
Date: Sat, 03 Mar 2012 12:09:05 -0800
From: IETF Secretariat <[email-masked]>
To: [email-masked],
[email-masked]

State changed to Approved-announcement to be sent from
Approved-announcement to be sent::Point Raised - writeup needed
ID Tracker URL:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/

---

From: Fernando Gont <[email-masked]>
Date: Sat, 03 Mar 2012 20:51:21 -0300

Hi, Joel,

This seems already too-late, but: it seems the comments I had sent were
not incorporated? (I didn't receive a response to my feedback, either).

Thanks,
Fernando

On 03/03/2012 07:33 PM, Joel jaeggli wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> 

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 04 Mar 2012 13:47:11 -0800

I read it at the time...

we had dropped the 2119 language/boilerplate entirely.

the prefix scanning ease issue is something I would dispute... common
address assignment methods already greatly facilitate subnet and
particularly router discover greatly. this doesn't seem likely to alter
that.

theres still the opportunity for nit language fixes in auth48 so ew
should consider that.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 05 Mar 2012 23:02:16 -0300

Hi, Joel,

> particularly router discover greatly. this doesn't seem likely to alter

But this would make scanning attacks even simpler. If anything, we
should move away from predictable addresses, rather than moving *to*
predictable addresses.

> theres still the opportunity for nit language fixes in auth48 so ew

Please note that I made other suggestions other than the one you're
referring to above.

Thanks,

---

From: Tina TSOU <[email-masked]>
Date: Wed, 07 Mar 2012 06:35:19 +0000

For your comments.
http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/

Sent from my iPad

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Date: March 5, 2012 5:09:49 PM PST
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt

A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfully submitted by Tina Tsou and posted to the IETF repository.

Filename:     draft-lopez-v6ops-dc-ipv6
Revision:     00
Title:         DC Migration to IPv6
Creation date:     2012-03-05
WG ID:         Individual Submission
Number of pages: 10

Abstract:
  This document describes the issues, possible solutions, and
  opportunities in Data Center (DC) migration from IPv4 to IPv6.  It
  focuses on the DC infrastructure itself, its operation, and the
  aspects related to DC interconnection through IPv6.  It does not
  consider the particular mechanisms for making Internet services
  provided by applications hosted in the DC available through IPv6
  beyond the specific aspects related to how their deployed on the DC
  infrastructure.

  Apart from facilitating the migration procedure itself, the
  mechanisms outlined here are intended to make this migration as
  transparent as possible (if not completely transparent) to
  applications and services running on the DC infrastructure, as well
  as to take advantage of IPv6 features to simplify DC operations,
  internally and across the Internet.

The IETF Secretariat

---

From: Washam Fan <[email-masked]>
Date: Wed, 7 Mar 2012 21:56:16 +0800

Hi,

I don't think the problem the draft is trying to address is clear.
Deduced from the solution, It seems to me the problem is to address
the IPv6 Internet accessing IPv4 network scenario. The solution seems
to me, is a variant of stateful NAT64. Compared to stateful NAT64, the
proposal is doing address translation whileas the statefull NAT64 is
doing address+port translation. And I don't know why the proposal is
integral to LB. It could have been an individual module even it could
be co-located with LB.

Finally, I feel it would be some overlap between this draft and
draft-carpenter-v6ops-icp-guidance.

Thanks,
washam

2012/3/7 Tina TSOU <[email-masked]>:
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
> A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfully
> submitted by Tina Tsou and posted to the IETF repository.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Mar 2012 08:14:51 +1300

Hi Washam,

> draft-carpenter-v6ops-icp-guidance.

I think the goals are rather different. -icp-guidance is aimed
at describing a process and a range of options for ICPs. -dc-ipv6
seems to be describing quite specific scenarios. Also data centres
are not the same thing as ICPs.

There's also overlap with draft-chkpvc-enterprise-incremental-ipv6,
although that is aimed at any kind of enterprise.

The three documents should aim at being consistent with each
other, but I think they have different audiences. I would definitely
be against combining them, because that would take for ever.

Regards
   Brian

---

From: Washam Fan <[email-masked]>
Date: Thu, 8 Mar 2012 11:20:54 +0800

Hi Cathy,

2012/3/8 Cathy Zhou(Qian) <[email-masked]>:
> Hi Wsham,
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Washam Fan
> Sent: Wednesday, March 07, 2012 9:56 PM
> To: Tina TSOU
> Cc: [email-masked]
> Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt
>
> Hi,
>
> doing address+port translation.
> //This solution is similar to stateful NAT64, but there are some differences. We say that is NAT64-Lite for this solution, using the same IPv6 prefix for the DC. For each service, IPv4 address is embedded into the IPv6 address (e.g. VSIPv6 formed: IPv6 prefix + VSIPv4+ other bits) . Via VSIPv4 embedded into VSIPv6, we don't need DNS64.

I don't think so, DNS64 would be used for the v6 clients to get VSIPv6
of the target services they is wanting to access. Or Could you
elaborate on how you publish those VSIPv6 to the v6 clients who is
attempting to access the corresponding services located in DC?

>In addition, the binding tables are only based on host IPv6 address, so we can reduce the number of binding tables(compared to RFC 6146-binding tables based on TCP/UDP sessions).

Yes. That why I said it is doing classical NAT whileas standard NAT64
is doing NAPT.

> And I don't know why the proposal is
> //You are right. It could be an individual module or co-located with LB.
>
> //Data Center and ICP are two different things, although they may use some similar IPv6 transition technologies, e.g., NAT.
>
Yes. But they should be consistent just as Brian pointed out.

Thanks,
washam

---

From: "Cathy Zhou(Qian)" <[email-masked]>
Date: Thu, 08 Mar 2012 03:56:52 +0000

Hi Washam,

-----Original Message-----
From: Washam Fan [mailto:[email-masked]] 
Sent: Thursday, March 08, 2012 11:21 AM
To: Cathy Zhou(Qian)
Cc: Tina TSOU; [email-masked]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt

Hi Cathy,

[Cathy]: The VSIPv6 and VSIPv4 addresses will both be published to the client. 
So the v6 client will get the address it needs without DNS64. 

[Cathy]: Agree.

Best Regards,
Cathy ZHOU

Thanks,
washam

---

From: Washam Fan <[email-masked]>
Date: Thu, 8 Mar 2012 12:24:22 +0800

Hi Cathy,

> So the v6 client will get the address it needs without DNS64.

Ok. Then would you mind to explicitly describe the publish process?
IMHO, DNS64 would be better used for this purpose.

Thanks,
washam