Subject: Re: [BEHAVE] draft-baker-behave-v4v6-framework-00

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Nov 2008 18:13:16 -0800

I have comments on several drafts that I've read queued up now,
but I haven't had time to convert my comments into plaintext.

Since it's getting close to IETF, I'll go ahead and send my marked up
PDF for now, since that's better than nothing.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Fred Baker
> Sent: Sunday, October 26, 2008 7:12 AM
> To: Behave WG
> Subject: [BEHAVE] draft-baker-behave-v4v6-framework-00
>
> I would invite comment on this
>
> On Oct 26, 2008, at 10:09 PM, IETF I-D Submission Tool wrote:
>
> >
> > A new version of I-D, draft-baker-behave-v4v6-framework-00.txt has
> > been successfuly submitted by Fred Baker and posted to the IETF
> > repository.
> >
> > Filename:      draft-baker-behave-v4v6-framework
> > Revision:      00
> > Title:                 Framework for IPv4/IPv6 Translation
> > Creation_date:         2008-10-26
> > WG ID:                 Independent Submission
> > Number_of_pages: 33
> >
> > Abstract:
> > This note describes a framework for IPv4/IPv6 translation.  This is
> > in the context of replacing NAT-PT, which was deprecated by RFC 4966,
> > and to enable networks to have IPv4 and IPv6 coexist in a somewhat
> > rational manner while transitioning to an IPv6 network.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: <[email-masked]>
Date: Mon, 17 Nov 2008 11:26:35 +0900

[DT24] Agree
[DT25] How about "entire IPv4 network address space." or "entire IPv4 network addresses."
[DT26] Agree
[DT27]
[DT28] Agree
[DT29] Agree

[DT30] Agree
[DT30] Agree
[DT30] Agree
[DT30] Agree
[DT30] Agree
[DT30] Agree
[DT30] Agree
------------------------------------
Hiroshi Miyata
Network & Software Development Dept.
Yokogawa Electric Corp.

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dave Thaler
> Sent: Saturday, November 15, 2008 11:13 AM
> To: Fred Baker
> Cc: Behave WG
> Subject: Re: [BEHAVE] draft-baker-behave-v4v6-framework-00
>
> I have comments on several drafts that I've read queued up
> now, but I haven't had time to convert my comments into plaintext.
>
> Since it's getting close to IETF, I'll go ahead and send my
> marked up PDF for now, since that's better than nothing.
>
> -Dave
>
> > > A new version of I-D,
> draft-baker-behave-v4v6-framework-00.txt has
> > > in the context of replacing NAT-PT, which was deprecated by RFC
> > > 4966, and to enable networks to have IPv4 and IPv6 coexist in a
> > > somewhat rational manner while transitioning to an IPv6 network.
> > >
> > >
> > >
> > > The IETF Secretariat.
> > >
> > >
> >

---

From: <[email-masked]>
Date: Mon, 17 Nov 2008 12:02:56 +0900

#Sorry for my previous email.
#I sent it when I was still working....

Thanks Dave for your comments.
Basically I agree with you in most points.
My comment is as follows.

[DT24] Agree
[DT25] How about "the entire IPv4 network addresses." or
       "the entire IPv4 network addresses space."
[DT26] Agree
[DT27] correct
[DT28] Agree
[DT29] Agree
[DT30] Agree
[DT31] Sorry, I can not got your point.
[DT32] The address would be assigned to IPv6 host administratively,
      like through statically configured rc file or dhcp. So the node would
      use the address when it boots.
[DT33] Agree
[DT34] I think the perpose of this is delegation of the administration of the prefix
       to the administrators of the smaller networks.
       e.g., from Entireprise administrator to Division administrators.

       Another point I found, In 2.2.2, there are two "Routing" articles.

[DT35] Sorry, I can not got your point.
[DT36] Agree
[DT37] Same as DT32
[DT38] Agree

> I have comments on several drafts that I've read queued up now, but I
> haven't had time to convert my comments into plaintext.
>
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave> > > > Number_of_pages: 33

---

From: Dave Thaler <[email-masked]>
Date: Sun, 16 Nov 2008 19:12:09 -0800

Quote from doc:
> Observing [RFC4291]'s requirement that an operator-specified prefix
> should have 64 bits of subnet locator and 64 bits of host interface
> identifier

What RFC 4291 actually says is:
> All Global Unicast addresses other than those that start with binary
> 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
> described in Section 2.5.1.  Global Unicast addresses that start with
> binary 000 have no such constraint on the size or structure of the
> interface ID field.

Hence the constraint of 64 bits applies only to prefixes that do not
start with binary 000.  Hence my comment on "operator-specified prefix"
having a 64 bit constraint was
"assuming it doesn't start with binary-000, right"

-Dave

---

From: <[email-masked]>
Date: Mon, 17 Nov 2008 19:43:21 +0900

Dave,

Thanks for your exlpanation.

Then, there are two alternatives for operator-specified /96 prefix.
a) The administrator need to be assinged another prefix starting with 000/3
b) The higher 24 bits of interface ID should be filled with OUI format, like ISATAP.

For me, b) seems to be better for easy operation and routing table size aspect.
For IVI prefix, only a) is available.

BTW
Is it possilbe to request prefix starting with 000/3 ?
# I am not familiar with the address assignment area.

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Monday, November 17, 2008 12:12 PM
> To: Miyata, Hiroshi ([email-masked]); [email-masked]
> Cc: [email-masked]
> Subject: RE: [BEHAVE] draft-baker-behave-v4v6-framework-00
>
> Hence the constraint of 64 bits applies only to prefixes that
> do not start with binary 000.  Hence my comment on
> "operator-specified prefix"

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Nov 2008 08:40:47 -0600

except that magic prefixes don't work very well in routing. They are a  
lot like the issues in site-local (another magic prefix), as I pointed  
out in the draft.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 17 Nov 2008 06:44:27 -0800

I wasn't suggesting operator-specified /96 prefixes, only that the
draft clarify.  For example, update the quoted phrase to say something
like:

   Because operator-specified prefixes today do not start with binary
   000, and hence [RFC4291] requires that they have 64 bits of subnet
   Locator and 64 bits of host interface identifier, ...

-Dave

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Nov 2008 08:47:50 -0600

>   Locator and 64 bits of host interface identifier, ...

OK, I can do that. My comment about routing not working was in reply  
to Miyata-san, whom I understand to want 0::/3 prefixes.

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Nov 2008 18:58:29 +0100

Hiroshi,

The good news is that there is a c) alternative, ref. sec 3.2.4 of
draft-despres-sam-01.

It uses the fact that IIDs of non 000/3 addresses never have 11 in bits
6 and 7 of their first octet.

RD

[email-masked]   (1-12/1-31/200x) 11/17/08 11:43 AM:

Dave,

BTW

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]]
Sent: Monday, November 17, 2008 12:12 PM
To: Miyata, Hiroshi ([email-masked]); [email-masked]
Cc: [email-masked]
Subject: RE: [BEHAVE] draft-baker-behave-v4v6-framework-00

Quote from doc:

All Global Unicast addresses other than those that start

with binary

000 have a 64-bit interface ID field (i.e., n + m = 64),

formatted as

described in Section 2.5.1. Global Unicast addresses that

start with

-Dave

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 16:05:38 +0900

Fred,

Actually, I don't want 000/3. ;-)
I just thought "how to compliant to 4291". no more no less. ;-)

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, November 17, 2008 11:48 PM
> To: Dave Thaler
> Cc: Miyata, Hiroshi ([email-masked]); [email-masked]
> OK, I can do that. My comment about routing not working was
> in reply to Miyata-san, whom I understand to want 0::/3 prefixes.
>
> > -Dave
> >
> >>> For me, b) seems to be better for easy operation and
> routing table
> >>> size aspect.
> >>>>> Observing [RFC4291]'s requirement that an operator-specified
> >>>>> prefix should have 64 bits of subnet locator and 64
> bits of host
> >>>>> interface identifier
> >>>>
> >>>> Hence the constraint of 64 bits applies only to prefixes that do
> >>>> not start with binary 000.  Hence my comment on
> "operator-specified
> >>>> prefix"