Subject: [BEHAVE] What is the purpose to consider the non-standard IPv6 address formats in NSP discovery using WKN?

From: [email-masked]
Date: Thu, 30 Jun 2011 19:16:34 +0800

Hello Everyone,

Setion 3.2 of draft-ietf-behave-nat64-discovery-heuristic-01 considers non-standard IPv6 address formats. I want to know the purpose. This condition violates what is described in RFC6052.Why not treat this condition as error? Even after performing more complex heuristics, a node finds the IPv4 address for the WKN, the node is difficult to decide the NSP from the returned IPv6 address.

Best Regards,
Zhenqiang Li
2011-06-30

---

From: <[email-masked]>
Date: Thu, 30 Jun 2011 19:13:20 +0000

Hi,

I wrote the text thinking that networks may some day have some reason to not follow RFC6052 guidance for the address format (or even new formats may be designed by IETF), but host at the same time has need to be able to detect the NSP.

Of the section 3.2 I agree cases 2 and 3 are quite long shots (and could be removed I think), but the case 1 of just different alignment of IPv4 address in NSP would be more reasonable to support.

The ability to fetch out NSP (suffix etc) correctly of non-standard format is of course a challenge (but failing connection is often bad user experience).

On the other hand, I don't see why a node should not attempt to detect non-standard NSP.

Best regards,

Teemu

-----Original Message-----
From: ext [email-masked]
Sent:  30/06/2011, 14:17
To: [email-masked]
Subject: [BEHAVE] What is the purpose to consider the non-standard IPv6 address formats in NSP discovery using WKN?

Hello Everyone,

Best Regards,
Zhenqiang Li
2011-06-30
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Jun 2011 21:26:49 +0000

> On the other hand, I don't see why a node should not attempt to detect non-standard NSP.

Detecting a non-standard NSP is only useful if the node understands how the nonstandard addresses are built, which presumably requires a bit more than simple pattern matching.

I think it would be simpler to place the non-standard NSP as firmly out of scope for the "standard" discovery draft. You can always add a simple paragraph, something like

"Developers MAY over time learn on IPv6 translated address format that are extensions or alternatives to the standard formats. They MAY at that point add additional steps to the proposed discovery procedures. These additional steps are outside the scope of the present document."

-- Christian Huitema