Subject: Re: (ngtrans) comments on SIIT 04

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Mar 1999 11:34:39 -0800 (PST)

>    This document specifies a transition mechanism in addition to those
>    already specified in RFC 1933.  The new mechanism can be used as part
>    of a solution that allows IPv6 hosts that do not have a permanently
>    assigned IPv4 address to communication with IPv4-only hosts."
> 
> The above abstract gives the impression that SIIT could be used in 
> combination with dual-stack hosts. I think it should explicitly say that 
> Only packets from/to IPv6 ONLY host may be translated.

That is not the intent but I can't understand what gives you that
impression. The first sentence is intended to state that the mechanism
doesn't intend to replace or superceed anything in 1933 but instead be
an addition mechanism for the "toolbox".

> 
> "1.  INTRODUCTION AND MOTIVATION
> ...
>    There are several different scenarios where there might be IPv6-only
>    hosts that need to communicate with IPv4-only hosts.  These IPv6
>    hosts might be IPv4-capable, i.e. include an IPv4 implementation but
>    not be assigned an IPv4 address, or they might not even include an
>    IPv4 implementation.
> 
>     - A completely new network ...
> 
>     - An existing network where a large number of IPv6 devices are
>       added..."
> 
> Up to this point you describe applicability and I think it is OK but 
> then you continue describing possible solutions that are out of scope of 
> SIIT.

Most of the remaining text is to give context by showing alternate solutions.
I'll add more explicit text where the section mentions address allocation.

> Later you say:
> "3.  OVERVIEW

> The whole of this section is dealing with something that is out of scope 
> for SIIT. How the translated packet reaches SIIT depends on the complete 
> solution and should be described in separate document see NATPT, BIS and 
> the IPv6 in IPv6 solution.

I agree.

> "3.1.  Assumptions
> 
>    The IPv6 nodes using the translator must have an IPv4-translated IPv6 
> address while it is communicating with IPv4 nodes."
> 
> Again this should not be here. "IPv4-translated IPv6" addresses should 
> be described somewhere else. Address assignment is dealt with in drafts 
> like NATPT, BIS and maybe you should write another draft about 
> IPv4-translated addresses...

I'm just stating 1) a requirement imposed by SIIT and 2) defining
the IPv4-translatable address.

Are you propsing that we reopen the addressing architecture document for #2?
(I hope not!)
I personally don't see an advantage to have a separate document (with
half a page of real content) just to define IPv4-translated IPv6 addresses.
What do others think?

   Erik

---

From: Bob Fink <[email-masked]>
Date: Fri, 19 Mar 1999 19:29:26 -0800

Erik,

At 11:34 AM 3/19/99 -0800, Erik Nordmark wrote:
...
>half a page of real content) just to define IPv4-translated IPv6 addresses.

I agree... it makes no sense to me either.

Bob

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 22 Mar 1999 10:30:36 +0000 (GMT)

> I'll add more explicit text where the section mentions address allocation.

Good, Thanks.

> > the IPv6 in IPv6 solution.

Great!

> half a page of real content) just to define IPv4-translated IPv6 addresses.

No, I did not mean that. A separate draft COULD be written if you wanted
to explain the combination of SIIT and v6inv6 tunnels solution as you
implied in the ngtrans meeting (and I am not sure if this involves
translatable addresses too or not since it has never been explained on
paper). Note that this is only if it makes sense to you and if it is
important.

I do not want to add work on your solders and I do not criticise the
essence of SIIT, which I think describes well the protocol translation
functions. My only concern is to make SIIT and its relation to other
documents more clear.

Thanks 

George
-----------------------------
Internet Transport Research |
BTLABS                      |
--------------------------------------------------------------------------
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of British
Telecommunications plc.
--------------------------------------------------------------------------