Subject: (ngtrans) Re: Last Call: Stateless IP/ICMP Translator (SIIT) to Proposed Standard

From: Thomas Narten <[email-masked]>
Date: Wed, 25 Aug 1999 15:51:20 -0400

I have some general comments about these two documents; I have some
editorial comments that I'll send in separate mail.

> o Stateless IP/ICMP Translator (SIIT)
>	<draft-ietf-ngtrans-siit-06.txt>

This document strikes me as being functionally incomplete (by itself),
and thus really isn't appropriate as a standards track document at
this time. Specifically:

1) It requires that originating hosts use special IPv4-translated
addresses, but does not specify how a host is to obtain them. Thus,
this document is not ready for implementation as is. This comment
specifically applies to the "stateless translater" part of this
document.

2) The document doesn't seem discuss source address selection rules,
yet I believe there is a requirement that when sending traffic to an
IPv4-translated address, the source address must also be an
IPv4-translated address. Thus, there are some implications for IPv6
nodes in general, independent of the siit box itself.

3) The document doesn't explain how a source host (in IPv6 land) would
obtain the IPv6-translated address of an IPv4 node. Is something like
DNS-ALG required?

Given the above, I don't believe the siit part of the document is
ready for advancement at this point.

Having said that, the siit document contains two orthogonal peices
that perhaps should be pulled apart into separate documents:

a) it defines how to do translation assuming that the IPv6 addresses
that will be used are IPv4-translated addresses (i.e., stateless
translation). It is a specific form of translation.

b) it defines in a lot of detail the mechanics of translating a v4
packet into v6 and vice versa. All of this function is generic to any
v4->v6 packet translation system and is what other documents might
want to refer to (e.g., natpt) in a normative sense.

> o Network Address Translation - Protocol Translation (NAT-PT] 
> 	<draft-ietf-ngtrans-natpt-06.txt>

This document uses siit in a normative fashion, but really only uses
part b) above, i.e, the mechanics. I suspect that siit is being
advanced now because of this part of the document, rather than the
siit functionality itself, which is still incomplete, IMO.

Would it make sense (and would Erik in particular be willing :-) to
revise the siit document to contain only function a), and pull the
material marked b) into a separate document? The result would be 3
documents:

1) a generic protocol translation document that described the
mechanics of translation. This document could be largely silent about
how one maps v4->v6 addresses and vice versa, but just assume that
some mapping would exist. (I.e, any document that referenced this
functionality would specify the missing pieces). Let's call this
document "6-to-4 Protocol Translation" or something similar.
 
2) natpt basically unchanged, but refering to the above document, and
filling in the gaps (i.e., the address mapping). Actually, some of the
text in natpt should either go into document 1) or removed as being redundant.

3) siit talking just about how one does translation using siit,
refering to the first document for the details of translation (modulo
issues specific to siit). Call this document "SIIT".

Also, the siit document says:

>            Source Address:
>                    If the IPv6 source address is an IPv4-translated or
>                    an IPv4-mapped address then the low-order 32 bits of
>                    the IPv6 source address is copied to the IPv4 source
>                    address.  Otherwise, the source address is set to
>                    127.0.0.1.  The use of 127.0.0.1 is to avoid
>                    completely dropping e.g. ICMPv6 error messages sent
>                    by IPv6-only routers.

However, 127 addresses aren't supposed to appear on the wire (RFC 1812
- -- router requirements says router SHOULD NOT forward them).
Certainly 127 addresses are on the bogon lists of many routers. Seems
to me that such packets should just be dropped. Or perhaps a different
reserved address be used, or just use the siit boxes address,
or... ???

In natpt:

>       In the opposite direction, when a DNS response traverses from  the
>       DNS  server  on the V6 network to the V4 node,  the  DNS-ALG  once
>       again traps the DNS packet and would:
> 
>          a)   Translate  DNS  responses  for "AAAA" or "A6" records into
>          "A" records, (only translate "A6" records  when  the  name  has
>          completely been resolved)
>          b)  Replace  the  V6 address resolved by the V6 DNS with the V4
>          address internally assigned by the NAT-PT router.

Seems to me like the above is saying drop A6 records that don't
contain a full address. But the whole point of A6 (when its
functionality is enabled) is that they won't contain complete
records. That is, if a site is using A6, does this mean that some
sites won't be able to reach it?  Seems like there may be a hole here
that needs more specification

>   5.3  TCP/UDP/ICMP Checksum Update

Most (all?) of the text in here could be moved to the "6-to-4 Protocol
Translation" document (this is a generic translation issue). The only
reason it is not in siit now is that siit doesn't need to update the
checksum for TCP/UDP because its choice of v6 addresses mean the
checksum doesn't change when translating between v6 & v4. 

Similar comments apply to Sections 7.3-7.5. Section seems to repeat
information that would more appropriately be covered in the k"6-to-4
Protocol Translation" document.

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Aug 1999 16:23:12 -0700 (PDT)

> specifically applies to the "stateless translater" part of this

You are correct that the address configuration part is explicitly not
part of the document.
But the WG still felt that it was worth-while to standardize the
translation rules.

There is work in progress (in the AIIH proposal) on how to acquire
temporary addresses which could be applied here in the future.

This seems analogous to the way MPLS is being handled - protocols
that use labels are being standardized even though there is no standardized
mechanism to determine the labels as the LDPs are still being worked on
in the WG. That doesn't seem to cause any problems.

So what are the rules?

> nodes in general, independent of the siit box itself.

Yes, when an IPv6 node is sending to an IPv4-mapped address
it must give preference to an IPv4-translated source address.
It would make sense to state this explicitly in the draft (even though
the "longest match - most common leading bits" IPv6 source address selection
rule will handle this for an IPv6-only node.)

> obtain the IPv6-translated address of an IPv4 node. Is something like

Huh?
It uses the IPv4-mapped address of the IPv4 node.
getipnodebyname() will return that one.

I realize I need to add the picture ip front pointing out that
the communication appears between an IPv4-translated address on the IPv6 node
and an IPv4-mapped address representing the IPv4 address of the IPv4 node.

> that perhaps should be pulled apart into separate documents:

I'll defer that question until we determine what "rules" apply compared to
e.g. the MPLS specifications. I'll just point out we've been down a similar
but not identical path before when NAT-PT was standalone by duplicating large
amounts of SIIT text. We clearly don't want to go there again.

Three documents only make sense if it is impossible to standarize SIIT due
to a perceived hole.

  Erik

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 1999 16:24:58 -0400

> You are correct that the address configuration part is explicitly
> not part of the document.  But the WG still felt that it was
> worth-while to standardize the translation rules.

Which translation rules? The ones specific to SIIT, or the ones
generic to any packet translation?  I agree that the latter should
move forward, but I'm less sure of the former. Hence my suggested
split.

> temporary addresses which could be applied here in the future.

Right. My concern is that this is one piece of bigger picture that is
not yet complete. So I don't see the urgency to get this out as a
PS. By making it a PS, we are in some sense saying "it's ready for
implementation", which I don't think is accurate in this case.

> rule will handle this for an IPv6-only node.)

OK. This isn't a big issue then.

> Huh?  It uses the IPv4-mapped address of the IPv4 node.

Big misconception on my part. My main concern just went away.

RFC 2373 says that a v4-mapped address indicates a node that
understands v4, but not v6. It seems odd for a source host to be
sending it v6 packets. In particular, this implies that the host knows
that there must be a translater present in order for it to be
originating v6 packets. If no translater is present, and a node
implements v6 only, no packets should be sent. Right? How does a host
learn this? Something for AIIH to specify? Is this consistent with the
current definition and intended usage of v4-mapped addresses? (I think
the answer is probably yes.)

> Three documents only make sense if it is impossible to standarize SIIT due

I'm not arguing that SIIT can't advance for process reasons. I am
questioning the need to advance it now.

Also, when the various documents are ready to advance to draft
standard, all parts of it will need to have been implemented. It seems
like it will be easier to advance natpt (for example) if it's not
tightly tied to siit (it only needs to be tied to the generic packet
translation issues). Also, aren't there other documents in the
pipeline (e.g., bump-in-the-stack) that want to reference the packet
translation rules, but not the siit-specific stuff?

Bottom line is I should have raised this issue back in February when
there was a more general discusion about how to structure the ngtrans
documents in general. If the folks (especially thouse who would need
to do the work) don't think its needed, I'll withdraw the suggestion.

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Aug 1999 15:24:33 -0700 (PDT)

> move forward, but I'm less sure of the former. Hence my suggested

I guess I should have said "the WG still felt that it was worth-while
to standardize SIIT".

> implementation", which I don't think is accurate in this case.

You can implementing it just fine - all you need is manual configuration
of the IPv4 translatable address.
That might not make it very useful, but I think it resolves the issue
of beging able to advance SIIT to DS so that we can move NAT-PT and
other specs which have normative references to SIIT to DS.

> learn this? Something for AIIH to specify?

The intent is that by configuring the IPv6 node with a translatable address
(whether manually or though some AIIH mechanism) you are implicitly
telling the node that there is a translator available.

> Is this consistent with the

As stated in RFC 2373:
   A second type of IPv6 address which holds an embedded IPv4 address is
   also defined.  This address is used to represent the addresses of
   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
   This type of address is termed an "IPv4-mapped IPv6 address" and has
   the format:

And in RFC 2133:
   The API also provides a different type of compatibility: the ability
   for IPv6 applications to interoperate with IPv4 applications.  This
   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
   addressing architecture specification [2].  This address format
   allows the IPv4 address of an IPv4 node to be represented as an IPv6
   address.

Thus as far as I can tell the use of mapped addresses in SIIT is consistent
with their definition and intent.

> questioning the need to advance it now.

You are arguing that there is a fatal hole due to there not being an
automatic way to configure IPv4-translatable addresses.

I don't think this is a fatal hole - merely a way to make incremental
progress on specifying protocol standards.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Aug 1999 21:01:02 -0700 (PDT)

> >                    completely dropping e.g. ICMPv6 error messages sent

This was already pointed out on the list.
I'll revise the document to specify 0.0.0.0 instead of 127.0.0.1
and we'll see how that flies.

  Erik

---

From: Bob Fink <[email-masked]>
Date: Fri, 27 Aug 1999 07:59:55 -0700

Thomas,

At 04:24 PM 8/26/99 -0400, Thomas Narten wrote:
...
>to do the work) don't think its needed, I'll withdraw the suggestion.

As Erik has pointed out, the working group wanted to advance these two in
this fashion. Going back over this ground will be difficult, so I favor
leaving as is, letting Erik and George/Suresh fix what's appropriate, and
move them forward.

Bob

---

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Aug 1999 12:08:22 -0400

Erik,

> progress on specifying protocol standards.

Based on the followup discussion, I now agree that leaving things as
they are is fine. Apologies for the distraction.

Thomas