Subject: [v6ops] draft-byrne-v6ops-clatip-00

From: "Dave Michaud" <[email-masked]>
Date: Mon, 4 Nov 2013 22:08:37 -0500

The discussion/controversy for this document seemed to be around the concept of reserving an address for 464XLAT use.

I think however, and this is my interpretation when I read the I-D, that the current intention is only to generalize a block already assigned for DS-lite so that it can be re-used for other transition technologies. The idea here is to provide an option for deploying 464XLAT. 

Mandating the use of this range may be inappropriate at this point but that is not what the current version of the draft does anyway.

Dave Michaud

This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.

Ce courriel (ainsi que ses pièces jointes) est confidentiel, exclusif, et peut faire l’objet de droit d’auteur et de privilège juridique; aucun droit connexe n’est exclu. Si vous n’êtes pas le destinataire visé ou son représentant, toute étude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut être illégale. Tous les messages peuvent être surveillés, selon les lois et règlements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas sécurisés et vous êtes réputés avoir accepté tous les risques qui y sont liés si vous choisissez de communiquer avec nous par ce moyen. Si vous avez reçu ce message par erreur, veuillez nous en aviser immédiatement et supprimer ce courriel (ainsi que toutes ses pièces jointes) de tout ordinateur ou support de données sans en imprimer une copie.

---

From: james woodyatt <[email-masked]>
Date: Tue, 5 Nov 2013 09:48:44 -0800

> Mandating the use of this range may be inappropriate at this point but that is not what the current version of the draft does anyway.

I finally figured out why this draft made me say "huh?" when it was presented.

When I was working on the IPv4 dial-tone features a certain home gateway implementation, I ran into a very similar problem.  I needed some IPv4 addresses to number the PPP interface when it was in its "connect-on-demand" state.  These addresses would never appear on the wire, because they were only used for triggering the PPPoE Discovery protocol in response to "outbound" DNS query packets.

The way I dealt with this problem was to use the old 0.0.0.0/8 "unspecified" prefix from the old days before CIDR. These numbers have never been either global scope or routable. They're pretty much useless on the wire. I don't see why you'd need an RFC to use them for 464XLAT purposes.

--james woodyatt <[email-masked]>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Nov 2013 11:44:59 -0800

Is there a reason the 100.64.0.0/10 prefix reserved for transitional technology implementations would be inadequate or inappropriate to this task?

Owen

On Nov 5, 2013, at 9:48 AM, james woodyatt <[email-masked]> wrote:

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Nov 2013 05:11:39 +0900

On Wed, Nov 6, 2013 at 2:48 AM, james woodyatt <[email-masked]> wrote:

> The way I dealt with this problem was to use the old 0.0.0.0/8"unspecified" prefix from the old days before CIDR. These numbers have
> never been either global scope or routable. They're pretty much useless on
> the wire. I don't see why you'd need an RFC to use them for 464XLAT
> purposes.
>

It appears that (at least some) IP stacks don't like 0.0.0.0/8. For
example, Linux returns EINVAL if I try to sendto() it (but I can bind to
it).

So unless you modified the stacks in question, you wouldn't be able to
support apps that sent packets to themselves. I know this sounds silly, but
unfortunately apps sometimes do silly things, and when you're a
compatibility mechanism trying to support legacy apps, you don't really get
to refuse to support apps just because they're silly.

(For example: Skype wouldn't work if it didn't have a default gateway IP
address; if it had a perfectly working point-to-point default route with no
default gateway, it decided that it didn't have connectivity. We ended up
giving it a default gateway of itself.)